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The  demand  for  software  products  has  grown,  but  the 
number  of  quality  programmers  has  not  kept  pace. 
Therefore,  programmer  prodcutivity  aas  become  a  major  area 
of  discussion  throughout  the  software  development  industry. 
This  paper  examines  the  various  measures  discussed  in  the 
literature  and  used  in  selected  corporations  which  develop 
software.  It  presents  several  methods  for  measuring 
programmer  productivity.  Included  ia  the  discussion  are  the 
salient  points  where  managers  must  devote  special  attention 
if  they  are  to  use  programmer  productivity  measures  effec¬ 
tively.  This  paper  is  part  of  a  group  of  papers  which 
together  provide  recoamea dations  to  the  Fleet  Material 
Support  Office  (FMSO)  to  enhance  its  software  development 
organization. 
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I.  £8ima£XI2! 


In  the  past  two  decades,  as  computer  hardware  costs  have 
fallen  and  software  costs  hare  risen,  there  has  been  an 
increasing  interest  in  programmer  productivity.  This 
interest  has  becoae  particularly  intense  daring  the  last 
decade  as  the  general  purpose  coaputer  market  has  flour¬ 
ished.  Customers  are  becoming  much  more  aware  of  the 
flexibility  that  different  software  packages  provide  to 
computer  hardware.  They,  therefore,  are  demanding  more  and 
more  software  products  to  upgrade  existing  hardware  facili¬ 
ties.  Withington  (Ref.  1  ]  of  Arthur  D.  Little  Inc.,  a 
Cambridge  (Mass.)  consulting  firm,  states  that  the  throt¬ 
tling  factor  in  the  evolution  of  the  data  processing 
industry  is  the  pace  of  software  development.  Revenues  in 
the  data  processing  industry  are  expected  to  reach  $95 
billion  by  1984  but  have  the  potential  to  reach  $125  billion 
if  the  software  development  constraint  did  not  exist.  This 
software  demand  has  precipitated  a  large  demand  for  program¬ 
mers.  But  programmers,  especially  skilled  ones,  are  hard  to 
find  and  take  time  to  train.  Since  there  has  been  such  an 
astronomical  growth  in  the  computer  software  industry, 
finding  sufficient  numbers  of  well  trained  and  experienced 
programmers  is  prohibitively  difficult.  [Ref.  2],  According 
to  Digital  Equipment  Corporation  'Ref.  3],  the  biggest 
problem  is  identifying  the  few  good  programmers.  Of  the 
many  applicants  they  receive,  most  are  not  capable  of 
writing  sophisicated  software.  Consequently,  software 
developers  are  turning  towards  increasing  the  productivity 
of  programmers  in  an  atteipt  to  keep  pace  with  the  demand 
for  current  and  future  software  design  needs. 


There  have  been  a  nuaber  of  papers  written  discussing 
productivity.  Soae  discuss  deteninants  of  progressing 
productivity  [Ref.  2],  others  provide  tools  [Ref.  4],  which 
purport  to  iaprove  productivity.  Interestingly,  few  of 
these  studies  discuss  or  make  reference  to  others  who  have 
discussed  how  to  actually  aeasure  this  productivity.  The 
philosophical  approach  for  many  years  was  that  programming 
was  an  art.  This  made  it  virtually  impossible  to  measure, 
for  it  would  be  similar  to  measuring  the  progress  or  produc¬ 
tivity  of  a  Picasso  or  Michelangelo  as  he  was  painting  or 
sculpting.  Obviously,  there  is  ao  way  to  measure  the 
progress  of  art  aside  from  personal  opinion.  This,  however, 
is  not  acceptable  in  an  industry  based  on  the  profit  motive. 
In  the  late  1960's  the  term  "Software  Engineering"  was 
coined  and  with  it  came  a  number  of  ideas  that  served  to 
pull  programming  out  of  the  world  of  art  and  into  the  world 
of  the  engineer,  a  world  where  measurement  is  of  vital 
importance.  Software  development  was  shown  to  be  an  area 
that  required  discipline  and  a  process-oriented  approach 
[Ref.  5]. 

Software  engineering  has  grown  through  the  1970's  to 
virtually  become  the  rule  for  the  management  of  programming. 
It  has  led  to  the  development  of  new  strategies  for  software 
development.  These  strategies,  top-down  design,  bottom-up 
design,  structured  prgram ming,  modular  decomposition  and 
metaprogramming,  have  provided  a  better  foundation  from 
which  software  developers  can  attempt  to  meet  the  growing 
demand  for  software  products.  Although  these  development 
techniques  have  made  software  development  easier  and  helped 
tc  control  the  cost  growth,  they  have  had  little  impact  on 
productivity  measurement. 

To  discuss  the  measuring  of  software  development  or 
programming  productivity,  one  must  first  determine  what  the 
product  is.  From  the  first  day  of  programming  until  the 


present,  the  predominant  product  of  discussion  has  been  the 
"line  of  code"  (LOC)  .  This  is  the  product  on  which  nearly 
all  research  and  the  database  information  are  based.  If  one 
were  a  construction  engineer  one  would  not  discuss  a 
building  or  bridge  based  on  the  nunber  of  bricks  and  girders 
used.  Instead,  rooms  or  floors  or  3pans  might  be  much  more 
appropriate.  These  items  are  integral  but  separately 
measureable  components  of  the  final  product.  So  why, 
rhetorically,  do  researchers  and  data  base  information 
collectors  continue  to  insist  on  LDC  measures  instead  of  au 
integral  and  separately  measureable  and  meaningful  component 
of  software  engineering?  This  not  a  question  for  this  paper 
to  answer  but  one  for  the  reader  to  consider  when  planning 
his  own  research  or  data  base  collection. 

The  Fleet  Material  Support  Office  (FMSO)  is  experiencing 
the  same  problems  as  the  rest  of  the  software  iniusrty.  It 
is  faced  with  a  huge  demand  for  quality  software  from  the 
organizations  it  is  tasked  to  support.  The  tasking  of  the 
past  five  years  is  shown  in  Figure  1.1  below.  These  figures 
are  only  for  the  Central  Design  Agency,  the  primary  mission 
of  FMSO.  The  figures  show  an  increase  in  FMSO  maintained 
programs  of  75. 4  percent  in  this  short  period.  These 
figures  are  expected  to  continue  to  rise  at.  a  significant 
rate  as  the  Navy  continues  to  automate  more  and  more  func¬ 
tions.  Another  problem  facing  FMSO  is  the  salaries  of  the 
programmers.  According  to  Business  *eek  [Ref.  S]  programmer 
salaries  are  rising  at  a  rate  of  15  percent  annually  and 
salaries  for  top  systems  analysts  can  reach  $50,000  a  year. 
This  places  an  extreme  burden  on  the  personnel  department  to 
acquire  top  personnel  when  hiring  new  programmers  and 
systems  analysts.  The  productivity  issue  becomes 

increasingly  critical  for  FMSD  in  the  light  of  the  hiring 
freeze  imposed  during  the  Carter  administration  and  the 
drive  to  reduce  the  cost  of  government  in  the  present  Reagan 
administration. 
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Figure  1.1  FBSO  Program  Library  Growth. 

This  paper  attempts  to  present  a  number  of  issues 
related  to  the  measuring  of  programmer  productivity.  It 
will  show  that  there  are  a  other  factors  that  impact  on  how 
one  interprets  the  productivity  figures.  The  manager  needs 
to  realize  there  are  several  different  levels  of  the  organi¬ 
zation,  each  with  its  cwn  product  cr  set  of  products. 
Therefore,  each  level  has  a  productivity  rating  for  which  it 
must  be  responsible.  In  fact,  the  reader  should  note  that 
the  programmer  is  not  the  predominant  link  in  the  output  of 
a  programming  project.  The  requirements  of  the  Department 
of  Defense  and  conscientious  software  developers  throughout 
the  industry  has  placed  increasing  importance  on  the  relia¬ 
bility  and  maintainability  of  software.  This  new  emphasis 
has  produced  a  whole  array  of  corresponding  products  which 
must  be  accounted  for  and  new  productivity  levels  which  must 
be  examined. 
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II.  nassi  EiQfiSS  IS  BSItLS  SfiASgSIB? 


when  discussing  productivity,  before  one  can  consider 
who  to  measure,  one  must  first  determine  what  the  product  is 
and  then  who  makes  the  product.  Without  a  rational  visuali¬ 
zation  of  the  product  it  is  unintelligent  to  discuss  the 
ability  of  a  person's,  group's  or  machine's  ability  to 
deliver  that  product.  Depending  upon  the  level  of  the 

organization  at  which  one  looks  there  will  be  a  variety  of 
goals,  objectives  and  products.  Both  Kiser  [Bef.  7,  p.  244] 
and  the  IEEE  Workshop  on  Software  Productivity  [Bef.  8] 
address  this  important  issue. 

Where  the  IEEE  Workshop  focused  on  the  general  area  of 
productivity,  Kiser  was  most  concerned  with  software  manage¬ 
ment  productivity.  She  focused  on  the  idea  that  the  manager 


often  has  as  much  to  do  with  a  programmer's  productivity  as 
does  the  programmer  himself  or  his  tools.  This  is  a  nontri¬ 
vial  issue.  She  looked  at  the  top  three  levels  of 


ccrp.  goals  <- 
product  goals  <- 
project  goals  <- 
task  goals  <- 


—  >  top  mgmt  <-- 

—  >  middle  <-- 

— >  first  line  <-- 


->  corp.prod 
->  product 
->  project 


— >  programmer  < - >  task 


Pigure  2.1  Kiser:  Levels  of  Note  m  Software  Productivity. 


management,  shown  in  Figure  2.1  .  Nany  managers  have  failed 
to  understand  why  their  people,  being  well- trained  and 


provided  with  excellent  tools,  conti 
tisfactory  levels.  Quite  often, 
experience  and  the  experience  provid 
production  level  is  caused  by  higher 
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concerned  with  profit  maximization  an 
being  part  of  the  public  sector,  do 
cular  concern  but  there  are  coiparabL 


nue  to  produce  at  unsa- 
froi  this  researcher's 
ed  by  Kiser,  the  poor 
level  aanagerial  poli- 
derstandable  when  one 
■anageient  levels, 
■anageient  is  usually 
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Figure  2.2  FNSO  Major  Hission  Areas. 


which  are  fleet  support  aid  effective  management  of  their 
approximate  S3. 8  billion,  FY82,  procurement  authority.  When 
one  considers  the  impact  of  money  management  at  this  level 
it  is  understandable  that  concerns  for  inaiviual  programmer 
productivities  can  get  lost.  The  interpretation  of  top 
level  management  polices  oy  lower  level  managers  can  also 
affect  productivity. 

At  the  middle  management  level,  managers  become 
concerned  with  specific  product  development  and  resource 
allocation.  For  FMSO,  in  its  primary  mission  area  as  a  CDA, 
management  is  concerned  rfith  allocation  of  resources  to 
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Figure  2.3  FMSO  0 DA  Primary  Product  Areas. 

respective  product  areas  as  shown  in  Figure  2.3  below.  The 
allocation  of  the  resources  is  tempered  with  the  command 
goals  and  the  budget  proviied  by  the  various  sponsors. 

The  first  line  level  of  management,  project  management, 
is  where  one  first  encounters  the  edge  of  software  produc¬ 
tivity,  the  area  with  which  this  paper  is  concerned.  Here 
the  project  manager  is  concerned  with  meeting  prescribed 
milestones  within  budget.  The  products  at  this  level  are 
the  various  "de liverables'1 ,  such  as  functional  specifica¬ 
tions,  conceptual  designs,  program  design,  test  plans,  etc., 
that  are  required  in  an  effectively  managed  project  with 
milestone  requirements.  These  are  the  products  one  must 
measure  against  their  respective  costs. 


13 


it  the  line  level  itself  there  ere  two  groups,  project 
teams  and  the  individuals  who  sake  up  the  teaes.  The  teas 
must  be  measured  against  i is  ability  to  deliver  integrated 
software  products.  The  individuals  mst  be  measured  against 
their  ability  to  deliver  specific  portions  of  the  team 
assignment.  This  is  the  point  where  programmer  productivity 
is  discussed  by  most  researchers.  A  special  note  is 
required  at  this  point.  While  one  usually  assumes  that  the 
delivered  products  are  of  a  specific  quality,  this  seems  to 
be  missed  quite  often  when  discussing  programmer  products. 
The  idea  of  quality  in  the  product  must  always  be  consid¬ 
ered.  A  person  who  can  deliver  five  programs  in  one  day 
that  are  incorrect  or  do  not  provide  consistent  results  is 
not  nearly  as  productive  as  one  who  delivers  one  product 
every  five  days  but  which  is  correct  and  easily  maintained. 
Very  few  productivity  measures  take  quality  into 
consideration,  as  will  be  shown  later. 

After  realizing  the  various  products  made  by  different 
levels  in  the  organization,  one  must  then  consider  who  is 
viewing  these  measures,  management  or  labor.  The  views  and 
concerns  of  each  are  usually  quite  different  unless  there 
has  been  a  considerable  amount  of  education  on  each  side. 

Management  must  understand  there  is  an  overhead  expense 
to  developing,  collecting  and  analyzing  productivity 
measures  which  must  be  justified.  Intuitively,  one  must 
have  a  set  of  measures  before  one  can  determine  constant, 
"normal"  or  changing  productivity.  Also  management  needs  to 
know  how  it  intends  to  use  these  measures.  The  IEEE 
[Baf.  8,  p.  341]  sees  f our  major  uses  for  productivity 
measures:  1)  motivation;  2)  understanding;  3|  evaluation; 

and  4)  management. 

Productivity  measures  can  be  used  for  motivational 
purposes  in  three  ways  which  provide  tangible  benefit. 
First,  researchers  [fief.  9,]  have  shown  that  by  paying 
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attention  to  a  person  or  group,  performance  levels  of  that 
person  or  group  will  improve  or  change  to  what  the  observee 
perceives  as  expected  performance.  This  is  known  as  the 
Hawthorne  Effect.  When  managers  take  the  time  to  do  produc¬ 
tivity  studies  the  Hawthorne  Effect  may  occur,  albeit 
teaporarily.  Second  is  the  ability  to  focus  attention  on 
desired  behaviors,  events  and  objects  or  products.  The 
measures  selected  will  place  relative  importance  on  the 
areas  being  aeasured.  Por  instance,  if  a  series  of 
measures  are  selected  which  include  speed  of  production  and 
maintainability  the  perceived  relation  between  them  by  the 
programmer  will  determine  which  measure  they  emphasize. 
That  perception  of  relative  importance  can  have  a  profound 
effect  on  the  final  product.  If  programmers  see  speed  being 
rewarded  or  emphasized  more  than  maintainability,  the 
manager  should  expect  to  see  programs  produced  rapidly  but 
which  are  hard  to  understand  and  have  little  documentation. 
If  the  reverse  is  perceived,  then  the  manager  should  expect 
to  see  longer  programming  times  with  much  easier  to  under¬ 
stand  and  better  documented  code.  The  third  motivating 
factor  occurs  through  feedback  of  results.  The  effective 
feedback  of  productivity  measures  can  lead  to  changes  in 
performance  in  several  ways.  Quite  often  performance  will 
improve  through  the  personal  pride  in  accomplishment  or 
competition  with  peers.  Also  if  a  corresponding  and 
effective  rewards  and  penalty  system,  either  formal  or 
informal,  exists,  performance  normally  will  follow  the 
system  correspondingly. 

Second,  productivity  measurements  help  managers  to 
understand  the  factors  underlying  productivity.  Measurement 
is  fundamental  to  science  in  that  it  forces  managers  and 
researchers  to  conceptualize  the  area  under  study.  Using 
various  concepts  will  determine  which  measures  to  use  as 
managers  continue  to  try  to  model  the  environment  in  which 
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they  operate.  Failure  to  develop  a  model  will  hinder 
managers  in  improving  performance  and  will  keep  software 
development  an  art  instead  of  a  science. 

Third,  productivity  measures  help  managers  evaluate 
performance  because  they  quantify  performance.  It  is  easier 
to  evaluate  performance  over  time  w* thin  a  single  group  or 
organization  because  the  leasures  remain  constant.  It  is 
also  very  important  to  track  performance  so  that  proper 
feedback  to  personnel  can  be  provided.  It  is  also  important 
to  evaluate  between  group3  to  see  how  one  stands  against  an 
industry  average.  This  has  proven  to  be  particularly  diffi¬ 
cult  for  software  developers.  Pew  groups  use  the  same 
measures.  Those  that  use  similar  sounding  measures  often 
have  significantly  different  definitions  for  the  individual 
parts  of  the  measure.  L3T,  which  will  be  discussed  later, 
is  a  most  common  area  of  disagreement.  Nevertheless,  it  is 
important  for  each  organization  to  establish  a  baseline  and 
to  build  a  database  of  information.  This  information  can 
then  be  used  for  measuring  the  evolution  of  methodologies 
and  technologies  used  in  software  development. 

Fourth,  productivity  measurement  imposes  a  managerial 
discipline.  Normally  managers  are  concerned  with  tracking 
progress  against  a  schedule  and  budget. The  consistent  use 
and  taking  of  measurements  can  be  extremely  helpful  in 
making  projections  of  progress  against  schedules  and 
budgets.  The  manager  must  remember  that  a  productivity 
measure  is  only  a  snapshot.  It  must  be  analyzed  in  relation 
to  its  environment.  In  particular,  managers  oust  realize 
the  difference  in  the  learning  curves  of  various  projects. 
A  "f irst-of-its-kind"  project  will  have  a  much  different 
learning  curve  than  a  simple  modification  to  a  generic 
project.  The  productivity  rates  will  normally  change 
proportionally  to  the  learning  curve. 


The  manager* s  need  Cor  Measures  and  his  goals  can  differ 
significantly  free  those  of  the  workforce.  Management  often 
wants  to  use  the  aeasures  to  identify  exceptional  perform- 
aers  or  those  who  need  added  training. 

The  workforce,  however,  nay  view  the  aeasures  as  a  way 
to  generate  either  aore  products  froa  the  sane  work  effort 
or  to  generate  the  sane  nuaber  of  products  froa  a  reduced 
workforce.  When  the  workforce  sees  the  second  side  there 
can  be  severe  implications,  particularly  if  they  are 
organized. 

The  workforce  will  rapidly  wonder  what  their  benefits 
will  be  froa  all  this  new  attention.  Hill  the  aeasures  lead 
to  aore  money  for  the  saae  hours,  the  same  money  for  less 
hours  for  the  good  perforaaers  and/or  lost  jobs  for  the 
poorer  ones?  In  an  effort  at  job  preservation,  productivity 
may  fall  or  stagnate  at  a  predetermined  level.  This 
researcher  has  seen  deliberate  productivity  stagnation  by 
bricklayers,  both  in  the  housing  and  steel  industries,  and 
by  electricians  working  for  a  telephone  company,  all  at  well 
below  reasonable  levels  of  capability.  For  one  to  think 
that  programmers  and  their  industry  would  not  tend  to  act  in 
a  similar  fashion  is  to  approach  this  area  with  tunnel 
vision.  This  may  become  a  primacy  concern  for  FMSO  where 
some  of  their  government  employees  aold  specific  3S  ratings 
and  incomes  based  on  the  number  of  personnel  they  manage. 
Command  level  management  must  take  care  in  the  introduction 
of  the  productivity  metrics  so  that  personnel  in  these  3S 
ratings  do  not  feel  that  their  jobs  or  ratings  are  in 
jeopardy  if  there  is  significant  iicre§se  in  productivity 
which  leads  to  a  reduction  in  force  (RIF) . 


Hi-  Sail  IS  IIS  E&2B2SX? 


This  researcher  has  determined  that  the  predominant 
measure  of  programmer  productivity  is  the  quantity  of  lines 
of  code  written.  This  leads  to  savecal  interesting  conclu¬ 
sions.  First,  the  programmer  only  writes  deliverable  code. 
Second,  the  programmer  is  the  single  dominant  entity  in 
software  development.  Aid  third,  there  are  no  other  rele¬ 
vant  products  or  by-products  in  a  software  development 
project.  Anyone  who  has  the  opportunity  to  study  or  to 
work  in  the  software  development  arena  realizes  the  fallacy 
of  these  conclusions.  Programmers  do  considerably  more  than 
write  deliverable  code.  There  ire  many  other  people 
involved,  each  adding  important  contributions  to  the 
project.  There  are  sevenl  equally  important  products. 

From  the  previous  chapter  it  was  noted  that  there  are 
many  levels  of  an  organization  whose  productivity  should  be 
measured.  Those  involved  in  software  development  realize 
that  various  levels  of  tie  organization  make  contributions 
to  the  various  products  of  each  project.  This  chapter  will 
look  at  the  different  products  that  this  researcher  feels 
are  relevant  to  the  measure  of  software  development  produc¬ 
tivity.  This  discussion  will  begin  with  middle  level 
management  and  work  towards  the  individual.  As  we  progress 
down  the  organization  the  product  will  become  easier  to 
grasp.  The  span  of  management  control  and  resource  respon¬ 
sibilities  will  decrease.  Therefore,  one  must  remember  to 
ensure  the  product  and  the  level  of  the  organization  match. 
All  too  often  people  are  evaluated  on  their  ability  to 
produce  a  product  which  they  were  not  assigned  to  produce 
nor  had  any  role  in  producing. 


Unfortunately  the  raider  will  find  in  this  section 
several  teres  that  have  aultiple  sellings.  This  is  inesca¬ 
pable  because  there  has  been  no  ncepted  set  of  standard 
definitions  within  the  software  development  industry. 

A.  PROJECTS  kS  PRODUCTS 

The  "contracted  project",  geaericallyr  is  a  software 
development  tasking  for  which  an  organization  contracts 
another  to  produce.  It  aay  consist  of  a  number  of  sub- 
projects  or  programs.  An  example  is  the  development  of  an 
operating  system  which  includes  a  job  scheduler*  process 
scheduler  and  file  manager*  Pigure  3.1  shows  the  various 
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Figure  3.1  Software  Development  Products. 


component  products  of  a  project.  The  project,  an  operating 
system,  must  integrate  each  of  these  various  parts  to  be 
complete.  Therefore,  the  question  of  productivity  here  is 
whether  or  not  the  project  can  be  delivered  on  budget  and  on 
schedule. 


If  the  contracted  project  is  largm,  as  in  the  operating 
systee  example,  it  will  be  broken  down  into  several  saaller 
projects*  which  I  call  "assigned  projects"  since  there  is 
little  choice  as  to  who  will  aanage  thea  once  the  contracted 
project  is  accepted.  The  assigned  projects  will  be  given  to 
several  project  aanagers  who  will  report  to  the  central 
contracted  project  aanager.  The  role  of  each  of  these 
project  aanagers  is  to  deliver  a  fully  complete  integrated 
operating  product. 

The  guestion  at  this  point  is,  "Are  these  good  items  by 
which  to  measure  productivity?",  res,  they  are,  for  several 
reasons.  First ,  for  t&j§  level  management  they  are  the 
only  products  that  are  produced.  Second,  the  reason  for  the 
manager  to  hold  the  particular  job  of  project  manager  is  for 
him/her  to  deliver  a  project  on  time,  within  budget  and  to 
the  satisfaction  of  the  customer  so  that  the  organization 
may  make  its  profit.  What  about  the  difference  in  languages 
used  or  the  sizes  of  various  projects?  These  questions  need 
to  take  their  rightful  place  in  the  data  base  of  information 
of  the  corporation.  Each  productivity  measure  has  a  set  of 
parameters  within  which  it  can  only  be  used.  There  is  a 
definite  need  to  know  how  capable  a  project  manager  is  at: 
1)  developing  any  project;  2)  using  a  specific  language;  3) 
developing  various  sized  projects;  h)  developing  machine 
dependent  projects;  5|  developing  first-of-its-kind 
projects;  or  6)  modifying  a  generic  project. 

Each  of  these  parameters  gives  added  insight  to  a 
project  manager's  productivity  rating.  The  first  lets  one 
know  hew  productive  he/she  is  relative  to  all  the  other 
project  managers  regardless  of  project  specifics.  Each  of 
the  other  measures  provide  additional  information  on  the 
relative  productivity  of  a  project  manager  within  the  diffe¬ 
rent  parameters.  Ose  of  all  of  these  productivity  ratings 
by  the  next  higher  level  of  management  may  improve  both 


levels  of  management's  productivity  provided  project 
managers  are  veil  Batched  to  projects  vhere  their 
productivity  is  highest. 

B.  MILESTONES  AM)  HAHA5BHB  HT/SOPPOBT 

At  this  point  it  aay  be  advantageous  to  discuss  a 
aanageaent  tool  that  aany  aay  consider  to  be  or  confuse 
with,  a  product.  A  "miles tone”  is  a  point  in  the  life  of  a 
development  project  when  a  deliverable  product,  as  listed  in 
Figure  3.1  ,  should  be  completed.  Many  would  think  that  the 
ability  to  meet  project  milestones  shows  great  productivity. 
This  is  not  true.  For  if  it  were  true,  first  the  milestone 
must,  in  fact,  aean  the  production  of  a  deliverable  itea. 
Second,  the  deliverable  itea  must  be  something  of  value  to 
the  project.  If  the  deliverable  is,  in  fact,  of  significant 
value  to  the  project  then  the  production  of  that  item  is  the 
basis  for  one's  measure  and  not  the  meeting  of  a  milestone. 
The  meeting  of  the  milestone  shows  only  that  the  project  is 
proceeding  as  planned.  The  milestone  has  no  other  inherent 
value.  That  is,  one  does  not  deliver  a  milestone  as  one 
would  a  program.  The  milestone  is  only  another  management 
tool  just  as  is  a  productivity  measure. 

Like  milestones,  Manage ment/Support  is  not  a  product  but 
a  management  tool.  However,  the  type,  quality  and  quantity 
of  the  support  must  be  considered  very  carefully. 
Managemer.t/suppo  rt  exacts  a  price  in  that  it  is  an  overhead 
expense.  Its  value  is  not  as  a  product  but  as  a  tool, 
nearly  all  presentations  discussing  productivity  refer  to 
the  management/support  tools.  This  is  where  the  vendors  and 
consultants  make  a  great  deal  of  noney.  They  speak  of 
productivity  improvement  and  the  aids  that  provide  it. 


There  are  two  parts  to  this  concept,  management  tools 
and  support  tools.  The  management  side  deals  with  systems 
that  help  predict  costs  and  tiae  schedules  and  those  that 
track  the  progress  against  the  predictions  and  plans.  it 
FHSO,  this  function  is  uaier  the  auspices  of  the  Management 
Department,  Code  92  [Bef.  10]  where  PAC-II  is  used  to  track 
and  DOD  MICRO  and  SLIM  are  used  to  estimate  software  costs 
and  tiae  schedules.  The  value  of  this  support  can  be  very 
subjective.  Often  the  value  of  the  management  aid  is  that 
it  gives  the  manager  much  more  confidence  in  his/her  deci¬ 
sions.  The  effect  of  the  use  of  these  kinds  of  tools  aay 
also  be  seen  on  the  ledger.  If  the  eysteas  help  management, 
all  else  being  equal,  one  would  expect  to  see  fewer  cost 
overruns  and  better  personnel  management. 

The  support  side  has  a  airiad  of  tools  that  predict 
sure-fire  ways  to  improve  productivity  dramatically.  These 
tools  include  various  design  procedures  (i.e.  structured, 
top-down,  modular  design) ,  on-line  programming  and  provision 
for  each  programmer  to  have  his/her  own  CRI  terminal  to 
mention  a  few.  T.C.  Jones  (Ref.  11]  discusses  more  of  these 
tools  and  their  respective  limitations. 

The  fact  that  manageaent/support  is  not  a  product  does 
not  minimize  its  importance.  On  the  contrary,  it  is  vital 
to  effective  software  development.  But  the  manager  must 
realize  that  the  addition  of  each  piece  of  management/ 
support  costs  money  for  which  accounting  must  be  made. 
Although,  there  are  many  management/support  systems  which 
may  improve  productivity,  the  indiscriminate  implementation 
of  their  use  will  not  necessarily  lead  to  productivity 
improvements.  The  use  and  expansicn  of  management/support 
is  an  area  worthy  of  farther  study. 


C.  DESIGH  AHD  FOICTIOHiL  S PBCIPIC1IIDHS 


Design  specifications  are  usually  thought  of  as  a 
product  cf  the  contracting  organization.  They  are  used  as 
the  basis  from  which  to  aalce  a  contractual  bid  and  to  write 
the  functional  specifications.  However,  the  design  specifi¬ 
cations,  as  delivered,  often  nust  be  rewritten  by  the 
contractor  in  close  conjunction  with  the  contracting  organi¬ 
zation  so  that  they  are  explicit  enough  to  properly  write 
the  functional  specifications. 

Both  Keider  (Bef.  12]  and  Howien  [Bef.  13]  discuss  the 
need  for  well  thought  out  and  well  written  design  specifica¬ 
tions.  Keider ' s  article,  "Hhy  Projects  Fail”,  shows  how 
poorly  planned  projects  waste  money  and  resources.  Howden’s 
article,  "Life-Cycle  Software  Valuation" ,  discusses  the 
need  for  project  design  specifications  to  meet  five  proper¬ 
ties.  First,  the  specifications  must  be  consistent 
internally  as  well  as  in  any  related  documents  or  other 
portions  of  the  project.  Second,  the  specifications  must  be 
complete.  They  must  be  examined  for  missing  or  incomplete 
information  requirements  and  to  ensure  data  properties  are 
included.  Third,  the  specifications  should  only  include 
necessary  items  without  redundancy  (not  to  be  confused  with 
hardware  redundancy  to  ensure  reliability).  Fourth,  the 
system  must  be  feasible  with  existing  technology  and  hard¬ 
ware.  And  fifth,  the  specifications  must  use  correct  math 
formulas  and  decision  tables. 

The  reader  should  recognize  tha t  the  validation  of 
design  specifications  and  functional  specifications  is  a 
nontrivial  task.  The  systems  analysts  who  validate  the 
design  specifications  and  who  write  and  validate  the  func¬ 
tional  specifications  must  be  held  accountable  for  their 
resource  use  in  the  production  of  these  products.  The 
specifications  need  to  be  examined  carefully,  as  discussed 


23 


above,  especially  when  one  considers  that  approximately 
forty  percent  of  a  projects  resources  are  used  in  the  design 
phase  [Ref.  37].  Poor  quality,  hers  is  very  difficult  and 
costly  to  try  to  overcome  later  in  the  software  development 
cycle. 

D.  LIVES  OF  CODE  AS  A  PBODOCT 

The  line-of-code  (LOG)  is,  by  far,  the  predominant 
measure  used  throughout  industry  to  discuss  program  size  and 
productivity  ratings  foe  all  levels  of  software  development. 
Interestingly,  though  the  entire  Industry  uses  LOC  as  a 
measure  of  product  definition,  few  agree  as  to  what  a  LOC 
is.  One  of  the  first  questions  asked  is,  "Do  you  mean  a 
line  of  object  cede  or  source  code?".  The  industry  has  had 
some  success  in  distinguishing  between  them  but  not  in 
choosing  one  or  the  other  as  a  universal  measure.  Source 
code  is  that  written  by  the  programmer  while  object  code  is 
the  compiled  code  stored  in  memory.  Source  code  is  more 
often  used  to  describe  programmer  productivity  than  object 
code  which  is  usually  used  to  define  the  quantity  of 
computer  memory  required  to  store  the  program  code 
[Ref.  14]. 

Assuming  one  has  settled  on  source  code  as  a  part  of  the 
measure,  what  determines  a  line  of  code?  Some  have  said 
each  line  or  statement  written  by  the  programmer  regardless 
of  length.  Others  try  to  force  the  line  to  have  eighty 
characters.  Still  others  try  to  define  it  by  statement 
punctuation  characters  by  language  (i.e.  periods  in  COBOL  or 
semicolons  in  PASCAL)  . 

If  this  weren't  bad  enough,  the  next  question  is, 
"Wnich  of  the  lines  are  'countable'?1.  That  is,  some  want 
to  differentiate  between  executable  statements,  data  decla¬ 
rations,  comments,  nondeliverable  debugging  or  testing  aids. 
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etc.  Ose  of  LOC  each  of  these  areas  must  be  explicitly 
defined  because  studies  have  shown  line  count  variations  of 
more  than  two-to-one  on  the  same  program  [Ref.  15]. 

After  the  LOC  is  well  defined  and  published,  one  aust 
watch  carefully  because,  just  as  the  aeasure  helps  manage* 
aent  to  rate  personnel,  so  does  it  help  personnel  to  promote 
themselves,  often  by  manipulating  the  rules  in  their  favor. 
Here  are  several  exaaples.  Dne  company  settled  on  every 
line  written  regardless  of  length.  After  some  examination 
of  several  programs,  lines  were  found  not  to  be  complete 
statements  nor  eighty  characters  in  length,  thus  padding  the 
true  productvity  levels.  Another  may  decide  to  use  eighty 
characters  as  the  defined  line.  In  this  case  it  would  not 
be  unusual  to  find  variables  with  extremely  long  names  or 
use  of  the  "blank"  character  to  fill  up  lines  and  thus  pad 
the  productivity  rating.  Paradoxically,  the  programmers  may 
be  forced  to  have  large  numbers  of  blank  characters  if 
management  requires  the  use  of  structured  programming  tech¬ 
niques.  Another  problem  is  that  programmers  may  fight  the 
use  of  higher  level  languages  so  they  may  program  in  a 
language  in  which  they  are  comfortable  and  which  requires 
more  lines  to  accomplish  the  same  task.  Jonas  [Ref.  15, 
p.11-43]  discusses  the  LOC  measure  more  extensively  than 
presented  here. 

Since  the  measure  is  so  difficult  to  define  and  may  lead 
zo  unacceptable  programming  practices,  as  stated  above,  or 
cause  paradoxical  conclusions,  as  discussed  in  the  following 
chapter,  this  researcher  feels  LOC  is  a  poor  produce 
measure.  However,  this  does  not  mean  to  say  chat  there  is 
nc  use  for  LOC  as  a  product  measure.  In  fact  it  is  the  only 
measure  available  when  on?  is  performing  maintenance  on 
programs  which  entails  changing  individual  lines  in  a 
program.  Therfore,  we  must  have  a  definition  for  a  LOC. 
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There  are  many  different  languages  in  which  one  can 
program.  since  each  has  its  own  rules  of  construction  the 
definition  of  a  LOC  will  necessarily  be  different  for  each 
language.  This  researcher  prefers  to  view  a  line  of  code  in 
the  context  of  a  complete  santence  or  phrase  of  spoken 
language.  Each  programming  language  has  a  defined  equiva¬ 
lent  of  a  complete  statement  or  phrase.  Just  as  Hemingway 
and  Faulkner  had  different  styles  of  conveying  information, 
so  will  programmers.  This  is  not  a  detriment  to  programming 
any  more  than  it  is  to  writing.  Programmers  will  settle 
into  standard  line  lengths  with  which  each  is  comfortable. 
As  long  as  management  is  satisfied  that  the  style  fits  well 
into  the  structure  of  the  language  then  there  should  be  no 
problem.  This  does  require  management  to  supervise  and  to 
train  those  that  are  not  consistent  in  their  own  programming 
or  are  far  from  the  ’•average"  line  length  of  the  rest  of  the 
programmers. 

The  countable  lines  should  be  those  that  are  vital  to 
the  program  quality  and  specific  language.  The  lines  that 
are  niceties  but  which  aid  in  the  readability  of  programs 
have  good  reason  to  be  in  programs.  They  should  be  counted 
but  not  with  full  credit.  The  comment  line  is  an  example. 
It  is  necessary  for  readability  but  a  one  hundred  line 
program  does  not  need  an  additional  hundred  lines  of 
comments.  Contrarty  to  others,  tiis  researcher  believes 
some  credit  should  be  given  for  comment  lines.  However,  to 
keep  verbosity  out  of  programs  due  to  comment  lines  and  to 
be  consistent  with  the  credit  given  for  reused  code 
(Ref.  16],  they  should  only  count  as  twenty  percent  and  then 
should  be  a  full  eighty  characters  long.  Lines  that  are 
executable  or  data  declarations  and  the  like  should  be 
counted  fully  as  one  line. 


II  LOC  is  used  as  a  measure  for  program  length,  it 
should  be  measured  as  a  block  of  LDC,  haing  at  least  one 
hundred  lines  ard  not  mire  than  one  thousand  lines  per 
block.  There  are  two  reasons  to  do  this.  Pirst,  each  block 
of  LOC  can  have  a  time  value  association.  This  allows 
developers  to  speak  in  terms  of  time  per  block  of  code. 
This  is  valuable  when  trying  to  estimate  the  time  required 
to  develop  a  program  estimated  to  be  some  number  of  blocks 
of  code  long.  Second,  code  must  have  an  intrinsic  quality. 
It  makes  little  sense  to  discuss  one  tested,  debugged  and 
documented  LOC.  But  it  does  make  sense  to  discuss  a  block 
of  code  with  the  same  qualities.  This  tends  to  force  the 
code  to  have  some  minimum  level  of  quality.  The  quality 
requirement  takes  into  consideration  the  time  spent  by  the 
programmer  in  writing  non-d elivered  test  code  and  debugging 
aids  and  in  correcting  logic  errors.  When  LOC  are  reused 
the  count  value  should  be  a  percentage  of  one  original  LOC. 
Basili  and  Freberger  [Bef.  16]  use  twenty  percent  in  their 
research.  This  researcher  recommends  starting  with  twenty 
percent  and  then  adjusting  it  according  to  the  percentage  of 
time  required  to  locate  reusable  code  instead  of  developing 
original  code. 

E.  MODULE  AS  PRODUCTS 

A  module  is  a  single,  intellectually  managabla  portion 
of  a  program  which  is  separately  conpilable  but  which  must 
have  connections  to  other  modules.  Its  size  is  variable  but 
it  contains  only  one  compLete  responsibility  assignment  of  a 
program.  It  has  only  one  entry  point  and  one  exit  point  and 
conforms  to  the  permitted  logic  structures  of  structured 
programming.  The  responsibility  assignments  are  determined 
during  the  design  phase  before  any  work  on  individual 
modules  is  begun.  One  of  the  key  areas  of  modular  design  is 


tha  selection  of  module  contents  basal  on  the  probability  of 
change  during  the  aaintanance  phase.  In  other  words,  assign 
those  portions  of  progra as/pro j acts  that  are  likely  to 
change  due  to  hardware  or  technology  to  their  own  respective 
modules.  The  advantage  gainad  by  this  bit  of  overhead  is 
found  in  the  cost  avoidance  which  follows  during  the  mainte¬ 
nance  stage,  where  up  to  seventy  percent  of  a  project’s 
costs  lie. 

There  is  a  paradox  concerning  maintenance  and  well 
written  code.  If  one  measures  productivity  during  the 
maintenence  phase  by  cost  per  defact,  a  popular  method, 
he/she  will  find  that  very  poorly  written  code  has  a  lower 
cost  per  defect  than  well  written  code.  This  occurs  because 
poorly  written  code  has  many  errors  which  programmers  must 
spand  much  time  correcting.  They,  therefore,  become  very 
familiar  with  the  program.  The  initial  costs  of  relearning 
tha  program  logic  are  spread  over  many  errors  in  poorly 
written  code,  and  over  very  few  errors  in  well  written  code. 
However,  the  total  cost  of  maintaining  well  written  code  is 
usually  much  lower.  If  one  were  to  take  the  same  well 
written  modular  code  and  compare  it  to  the  same  well  written 
non-modular  code  one  should  find:  1)  fewer  logic  errors 
because  of  the  extensive  analysis  during  the  design  phase; 

2)  it's  easier  to  locate  errors  since  they  can  often  be 
traced  to  one  module  or  at  least  to  a  branch  of  the  program; 

3)  it's  easier  to  relearn  the  logic  because  of  the  need  to 
only  learn  one  or  a  few  modules  instead  of  the  entire 
program.  If  any  or  all  of  these  points  are  realized,  FMSO 
could  save  a  great  deal  in  resources  and  improve  customer 
satisfaction.  Since  FSSO  presently  must  maintain  over  9U00 
programs  and  respond  to  ever  3203  program  trouble  reports 
(PT R )  annually,  any  reduction  in  the  cost,  in  time  or  money, 
on  a  per  item  basis  could  lead  to  significant  savings  and 
higher  productivity  ratings  for  program  maintenance 
per  sonnel. 
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The  use  of  nodular  prog  Tanning  allows  two  other  areas  to 
be  explored.  The  first  is  Parnas'  [Ref.  17]  idea  of  progran 
fanilies.  The  idea  is  to  look  at  similarities  in  programs 
before  looking  at  thair  differanoas  and  write  generis 
programs  based  on  the  similarities.  Then  one  adds  the 
modules  that  will  make  the  programs  individualistic.  In 
this  way  progran ners  can  reuse  existing  code  which  is  well 
tested  and  with  which  programmers  are  thoroughly  familiar. 
This  helps  to  reduce  initial  project  development  time  and 
costs  and  to  reduca  maintenance  costs. 

The  second  area  is  that  which  Zoll  [Ref.  18  ,  p.  51] 
refers  to  as  " metaprogramning" .  Phis  is  the  use  of  data 
base  libraries  of  modular  code  to  build  complete  programs. 
The  code  is  generic  and  the  metaprogrammer  merely  researchs 
+-he  data  base  and  selects  those  modules  which  will  meet  the 
program  logic.  In  this  way  prograamers  write  much  less 
original  code.  Lanergan  and  Poynton  [Ref.  19]  report  that 
at  Raytheon  Company  some  new  applications  software  have  baen 
developed  forty  times  faster  than  by  using  traditional 
development  methods.  Reused  modules  have  been  averaging 
between  forty  and  sixty  percent  of  the  total  LOC  on  major 
projects.  The  probability  of  inducing  logic  errors  is 
reduced  significantly  and  the  probability  of  textual  errors 
is  also  reduced  due  to  the  reduced  amount  of  original  code 
required.  Kendall  and  Lamb  [Ref.  23],  in  thair  research  at 
IBM,  have  reported  data  which  shows  that  metaprogramming 
from  a  data  base  of  modules  should  be  seriously  considered. 
Their  study  showed  that  eighty  percent  of  the  applications 
programming  effort  goes  into  production  of  programs  whose 
used  life  is  less  than  eighteen  mouths.  Therefore,  any 
reduction  in  the  effort  to  develop  these  programs  and  any 
reduction  in  the  maintenance  effort  of  these  programs  will 
provide  a  factor  of  four  increase  in  the  savings  to  be 
apoliea  to  the  maintenance  of  the  twenty  percent  portion  of 
the  programs  with  a  siginf icantly  longer  life  cycle. 
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The  added  attraction  of  aodular  code  is  the  idea  of 
coapleteness  of  the  task.  For  a  quality  aodule  to  be  deliv¬ 
ered  for  integration  it  must  be:  It  documented;  2)  coded  in 
its  entirety;  3)  tested;  and  4)  debugged.  These  are  much 
more  difficult  tc  attain  with  LOC  as  the  product.  In  parti¬ 
cular  ,  it  is  very  difficult  to  test  a  block  of  LOC  since  it 
relies  heavily  on  the  remainder  of  the  code.  Therefore,  it 
can  only  be  examined  by  inspection  while  modules  can  be 
inspected  and  machine  debugged  to  a  near  zero  defect  condi¬ 
tion  prior  to  integration.  Although  the  documentation  is 
not  vital  for  module  delivery,  it  can  be  and  should  be  an 
organizational  requirement. 

The  idea  of  designing  projects,  especially  large  ones, 
by  dividing  them  into  subprograms  or  modules  is  a  very  old 
concept  in  programming.  During  the  1970's  it  became  a  topic 
of  high  interest  as  a  way  to  improve  program  reliability  and 
maintainablility .  Boss  et  al  (Ref.  21],  Liskov  (Ref.  22], 
Crossman  (Ref.  23],  and  Parnas  *Ref.  24]  [Ref.  17]  wrote 
formidable  papers  extolling  the  virtues  of  modular  program¬ 
ming.  let  there  are  many  software  development  organizations 
that  do  not  understand  the  term,  use  or  value  of  modular 
programming.  The  Department  of  Defense  (DOD)  appears  to  be 
one  organization  that  does  not  fully  understand  the  value  of 
modularization  and  reusing  code.  Munson  [Ref.  25]  points 
this  out  ir.  his  short  paper  on  reducing  software  costs  by 
reusing  code.  Elshoff  [Ref.  26]  observed  this  problem  at 
the  General  Motors  Research  Lab  wnere  modularization  not 
only  appeared  foreign  to  analysts  and  programmers  but  was 
viewed  as  detrimental  to  the  software  life  cycle.  The 
unfamiliarity  with  modularity  is  also  present  at  the  US 
Navy's  Fleet  Numerical  and  Dceanographic  Center  in  some 
analysts  and  programmers.  While  this  does  not  appear  to  be 
a  problem  at  FMSO  at  the  present,  internal  training  may  be 
required  because  of  turnover  of  software  development 


This  section  concerns  quality  aodules.  These  are 
nodules  that  are  coded  in  their  entirety,  tested,  debugged, 
and  documented.  Each  organization  will  have  to  set  up  the 
requirements  for  a  countable  module.  This  researcher  recom- 
mends  these  attributes.  They  ensure  attainment  of  the 
organization's  minimum  quality  standards  and  take  into 
consideration  the  programmer's  tine  in  debugging  and  testing 
the  module.  When  reused  modules  are  a  part  of  the  delivered 
product  they  should  be  cour.ad  as  a  percentage  of  one 
module.  Basili  [Ref.  15]  used  twenty  percent  in  his 
research.  This  is  a  good  starting  point.  But  if  the 
organization  finds  that  this  is  not  an  accurate  percentage 
of  the  time  required  to  develop  original  modules  then  the 
percentage  should  be  adjusted  accordingly. 

F.  USER  FOHCTIORS  AS  PRODUCTS 

The  previous  section  dealt  with  functions  based  on 
program  structure.  This  section  deals  with  functions  based 
on  user  requirements.  While  modules  may  vary  in  length  by 
approximately  one  hundred  lines  of  code,  user  functions  can 
vary  up  to  several  programs,  An  example  of  this  is  a  single 
entry  accounting  system.  A  company  may  want  a  system  which 
performs  several  functions  such  as:  ledger  maintenance, 
invoicing,  file  maintenance,  weekly  reporting,  etc.  Each  of 
these  operations  or  functions,  is  a  deliverable  product  to 
the  customer  as  a  part  of  the  single  entry  accounting 
package.  The  quality  of  the  entire  package  is  determined  by 
the  customer  satisfaction  with  each  individual  function. 
Albrecht,  [Ref.  27]  of  IBM  Corporation,  uses  this  measure  as 
the  primary  means  of  determining  productivity  ratings  in  the 
Applications  Development  3roup.  He  points  out  that  one  must 
be  careful  when  using  this  measure  or  any  other  measure  by 
keeping  the  major  project  objectives  in  perspective:  on 
time,  within  budget,  and  a  satisfied  customer. 


The  specific  product  leasure  is  what  Albrecht  calls  a 
function  value.  The  approach  to  determine  the  function 
value  is  to  count  the  number  of  external  user  inputs,  inqui¬ 
ries,  outputs  and  master  files  that  the  project  must  develop 
as  a  part  of  the  user  requirements.  An  external  user  input 
is  a  communication  from  the  user  to  the  computer  such  as 
data  forms,  terminal  screens,  keyboard  transactions,  optical 
scanner  forms  and  the  like.  These  do  not  include  inputs 
from  tapes  and  data  sets,  which  are  considered  as  internal 
and  part  of  the  file  count.  Each  of  these  user  functions  is 
weighted  by  a  value  designed  to  reflect  that  function's 
value  to  the  customer.  Appendix  r  shows  the  details  of 
determining  the  function  value  and  Appendix  II  shows  the 
details  of  determining  the  sizing  and  complexity  of  an 
entire  project  using  function  value  components.  Appendix  II 
uses  the  same  external  user  inputs  and  some  internal  inputs 
as  components  to  compute  the  function  points  but  also 
provides  for  the  the  computation  of  a  development  time  esti¬ 
mation.  It  is  important  to  note  that  Chrysler  [Hef.  2] 
showed  in  an  unrelated  and  independent  study  that  these 
components  were  most  significant  in  predicting  development 
time. 

Albrecht's  function  value  concept  has  several  advantages 
over  those  measures  previously  mentioned.  First,  it  is  the 
only  measure  that  deals  specifically  and  directly  with  user 
satisfaction.  The  other  ueasures  virtually  ignore  the  user 
between  the  functional  specification  phase  and  the  implemen¬ 
tation  phase.  This  method  constantly  works  with  the  user. 
Secondly,  since  its  focus  is  on  user  requireaents  and  not 
on  counting  lines  or  blocks  cf  code  or  modules,  it  tends  to 
liait  programmer  gaming  to  improve  his/her  productivity 
rating  artificially.  Third,  the  measure  breaks  the  project 
into  user  defined  portions  of  importance.  This  focuses  the 
effort  towards  teamwork  since  it  requires  the  development 
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group  to  work  as  a  teaa  toward  the  production  of  functions 
to  which  the  user  has  placed  a  wall  defined  inportance. 
Lastly,  the  aethod  providas  more  opportunity  for  a  smoother 
evolution  of  change  than  the  others.  It  focuses  attention 
on  the  cost  of  each  function  and  the  effects  on  cost  of 
aid-development  changes.  The  constant  attention  to  cost  and 
user  involvement  provides  a  better  lechanism  to  control  the 
change  process  during  development.  It  enables  the  planner 
to  design  for  changes  that  may  occur  during  the  life  cycle 
that  may  not  be  cost  effective  to  include  during  the 
development  phase. 

The  function  value  concept  has  three  disadvantages. 
First,  there  may  some  question  as  to  whether  to  call  a 
component  an  inquiry  or  an  input.  These  are  not  always 
distinct  items.  If  the  weighting  factors  are  different  for 
each  this  may  significantly  alter  the  final  function  value. 
Second,  users  play  a  large  part  in  determining  the  weighting 
factors,  as  it  should  be.  Users  can  be  fickle,  therefore, 
it  is  often  extremely  difficult  to  get  them  to  admit  "truth¬ 
fully”  what  they  desire  most.  It  is  not  so  much  that  they 
are  hiding  information  but  that  they  don't  really  know  what 
they  want.  Therefore,  it  requires  talented  interviewers  and 
designers  to  determine  the  true  desires  of  the  users.  The 
third  disadvantage  is  that  this  measure  is  so  good  that 
managers  may  tend  to  rely  on  it  too  heavily.  This  is  not 
the  ultimate  or  universal  measure  but  it  is  a  good  one.  The 
other  measures  can  give  insights  on  products  and  produc¬ 
tivity  that  this  measure  can  not.  The  function  value  is  an 
aggregate  measure  and  must  be  used  as  such.  As  Stevens 
[Raf.  28]  of  Performance  Management  Associates  Inc.  of 
Scottsdale  (Az. )  points  out,  there  is  no  universal  measure 
yet.  Ve  must  use  ail  the  imperfect  measures  available  in  an 
effort  zc  describe  the  programming  activity. 
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6.  TESTING,  IHT  BGB1TI0H,  1ND  I HPLEHENT1TION 


One  of  the  concerns  of  managers,  whan  discussing 
programmer  productivity,  is  how  to  incorporate  non-delivered 
code  in  the  calculation  of  productivity.  The  non-delivered 
code  consists  of  test  cods,  debugging  aids  and  incorrect 
code.  The  incorrect  coda  is  a  function  of  the  programmer's 
skill  and  is  a  penalty  to  his/her  productivity  rating.  The 
test  code  and  debugging  aids  are  not  mistakes.  They  are 
usad  by  skilled  programmers  to  ensure  coding  guality  and 
correctness.  There  has  been  some  concern  that  the 
programmer  should  have  this  code  included  with  the  delivered 
code  for  productivity  calculations.  This  researcher  does 
not  concur  that  the  test  code  and  debugging  aids  should  be 
included.  The  programmer's  job  is  to  deliver  code  that 
meats  the  specifications.  The  only  way  to  ensure  the  code 
actually  meets  those  specifications  is  to  perform  some  type 
of  test.  Test  code  and  debugging  aids  are  tools  of  the 
programmers  just  as  milestones  and  management/support  are 
tools  for  others  in  the  software  development  arena.  They 
are  a  necessary  overhead  which  programmers  must  employ  if 
they  are  to  deliver  the  guality  products  discussed 
pre  viously. 

The  integration,  testing  and  implementation  phase  of 
software  development  utilizes  approximately  forty  percent  of 
the  project's  resources  [8ef.  37  ,p.18].  Intuitively,  one 
would  think  that  an  area  which  uses  so  much  of  the  resources 
would  be  a  prime  place  to  do  soma  productivity  research. 
This,  unfortunately,  is  not  the  case.  One  of  the  prime 
reasons  has  been  the  inability  of  the  industry  to  determine 
the  role  these  activities  play.  Specifically,  there  is  a 
question  as  to  whether  testing  is  a  part  of  development  or  a 
part  of  quality  assurance.  If  it  is  part  of  guality  assu¬ 
rance  then  it  is  an  overhead  and  not  a  productivity  concern. 
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If  it  is  a  part  of  development  then  the  product  is  tested 
and  acceptable  code.  Bat  what  deter  sines  how  productive  the 
testing  is?  The  time  axpanded  in  testing  does  not  help  to 
determine  the  productivity  of  testing  because  the  tiae  used 
in  testing  is  a  function  of  the  test  plan  and  the  number  of 
defects  found.  Defects  found  does  help  to  determine  produc- 
tivity.  It  shows  either  poor  design,  poor  programming,  poor 
quality  assurance  practices  or  any  combination  thereof. 

Integration  is  left  with  the  same  type  of  problems. 
This  activity  takes  project  portions,  modules,  LOC,  or 
programs,  and  brings  thei  together  to  fora  a  cohesive  and 
integrated  product.  But  if  there  are  major  difficulties 
encountered  are  they  the  the  fault  of  the  integrators? 
Probably  not.  The  fault  probably  lias  with  the  designers  or 
the  programmers. 

The  manager  must  be  aware  of  tha  problems  that  develop 
during  this  phase  and  keep  records  of  them.  Though  there 
were  no  conclusive  reports  found  on  how  to  deal  with  the 
information,  the  consensus  from  tha  literature  is  that  it 
must  kept  in  a  data  bass  for  later  study  and  consideration. 
Tha  science  of  software  development  has  not  progressed  far 
enough  to  completely  handle  the  test,  integration  and  imple¬ 
mentation  problem.  Most  researchers  are  of  the  belief  that 
if  we  get  control  of  the  development  process  in  a  scientific 
way  these  problem  areas  may  disappear. 

H.  DOCOHENTATIO  N 

The  primary  belief  in  the  indusrty  and  particularly  in 
DOD  is  that  software  development  projects  have  two  separate 
products:  program  code  and  program  documentation.  This  is 
ar.  extremely  s hcrt-sighte d  but  understandable  belief.  As 
long  as  software  development  is  viewed  as  having  two 
products,  this  belief  presents  the  opportunity  to  discard 


one.  Since  the  program  is  what  is  wanted,  all  too  often  the 
documentation  is  reduced  ia  an  attempt  to  reduce  development 
costs.  The  view  that  there  are  two  products  and  the  prac¬ 
tice  of  reducing  the  documentation  thrive  on  the  belief  that 
software  development  and  software  maintenance  are  not 
related.  This  is  not  true.  The  documentation  is  required 
to  learn  the  program  logic  and  coding  structure,  k  software 
project  that  was  poorly  designed  and  poorly  or  not 
documented  is  extremely  difficult  and  much  more  costly  to 
maintain  than  one  that  was  well  designed  and  well  docu¬ 
mented.  Nearly  every  other  industry  (i.e.  automobile, 
electronics,  machine  tools,  etc.)  that  produces  a  complex 
product  provides  documentation  on  tie  logic  and  design  of 
that  product  so  that  maintenance  personnel  can  provide 
quality  and  cost  effective  maintenance.  There  is  no  reason 
to  believe  that  the  software  development  industry  should  be 
any  different. 

This  researcher  believes  that  documentation  is  not  a 
separate  product  but  an  integral  pact  of  all  well  developed 
software  projects.  This  chapter  consistently  discussed 
fully  coded,  well  documented  quality  software.  It  should  be 
intuitively  obvious  that  a  program  that  does  not  operate 
properly  is  of  little  or  no  value.  Und  that  one  that  oper¬ 
ates  properly  but  is  difficult  to  inderstand  and  maintain 
because  of  poor  documentation  is  of  auch  less  value  than  one 
with  superior  documentation.  Thus,  the  documentation  has  no 
specific  measure  of  length  only  one  of  quality.  It  is  a 
problem  for  the  developers  and  quality  assurance  experts  to 
ensure  that  the  documentation  is  provided  and  adequate  in 
describing  the  program  logic  and  coding  structure  of  the 
pro  ject. 
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17.  sgg  &S4S3&SS 


During  the  research  far  this  piper  it  vas  noted  that 
there  is  a  great  deal  of  al sunierstaading  both  in  the  liter¬ 
ature  and  in  the  industry  about  programming  and  software 
development  productivity.  The  misunderstanding  lies  in  the 
area  that,  when  questioned  about  the  product  that  is 
produced,  one  will  receive  quizzical  looks  or  long  spells  of 
silence.  People  immediately  want  to  jump  to  discussions  on 
complexity,  language,  tools  or  the  development  environment. 
These  have  little  to  do  with  calculating  productivity. 
Their  roles  are  as  parameters  within  which  one  must  analyze 
the  specific  productivity  rating.  This  is  not  to  belittle 
the  importance  of  these  areas.  It  is  simply  a  matter  of 
organizing  one's  thoughts.  One  can  not  intelligently  speak 
of  improving  productivity  until  one  first  has  a  quantitative 
measure  and  secondly  a  description  of  the  environment.  Too 
often  people  in  the  industry  look  at  the  environment  not 
only  first  but  exclusively.  Without  a  product  definition 
and  the  measure,  the  environment  cannot  be  understood. 

Productivity  has  two  components:  outputs  and  inputs. 
The  outputs,  loosely  defined,  are  the  products  previously 
discussed:  projects,  programs,  functions  points,  modules, 
and  LOC.  They  are  dependent  on  the  corporate  hierarchical 
level  and  the  philosophy  used  for  software  development.  The 
inputs  vary  considerably  depending  upon  which  productivity 
measure  one  is  interested.  The  most  common  input  used  is 
the  person-month,  160-175  hours.  This  can  be  broken  down 
into  its  various  parts  by  programmers,  mar.agement/support, 
systems  analysts,  and  program  analysts.  But  there  are  other 
inputs  that  may  be  worth  considering  such  as  CPU  time  or 
terminal  connect  time.  Though,  these  are  rarely  if  ever, 
considered. 
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A.  LOC  FEB  PROG  BAH  HEB-BOBTH 


The  most  coaaon  measure  used  for  assessing  productivity 
throughout  the  industry  is  LOC  per  programmer-month.  Though 
a  very  popular  measure,  it  is  not  vsry  good.  Since  if  is 
based  on  LOC  it  is  subject  to  the  Line  counting  variations 
oentioned  in  the  previous  chapter.  This  variation  can  be 
liaited,  to  a  certain  at  tent,  by  setting  organizational 
standards  as  rec  amended  aarlier.  This  would  permit  consis¬ 
tency  in  the  organization  but  not  across  the  industry. 
Recall,  one  of  the  reasons  for  measuring  is  to  make  compari¬ 
sons  across  organizational  lines.  As  long  as  there  are 
variations  in  the  definitions  of  ooaponents  no  intelligent 
comparisons  can  be  made. 

LOC  per  programmer- mon th  is  ineffective  for  noncoding 
tasks.  The  tendency  when  computing  this  measure  is  to  use 
programmer-month  as  tha  total  development  time  which 
includes  these  noncoding  tasks  of  iasign,  documentation, 
testing  and  management/support.  Since  no  coding  is  going  on 
during  these  stages  it  makes  little  sense  to  include  them  in 
the  coding  effort.  Tharafore,  that  would  imply  that  this 
measure  should  be  used  only  for  tha  coding  phase.  Of 
course,  that  focuses  attention  on  tha  coding  task  exclu¬ 
sively,  which  is  a  minimal  portion  of  the  software 
development  effort. 

Finally,  this  measure  tends  to  penalize  high-order 
language  (HOL)  programs  in  favor  of  programs  written  in 
Assembler  language.  Jonas  [Raf.  29,  p.  21]  provided  tha 
example  shown  in  Figure  u.  1  .  This  is  an  example  of  tha 
same  program  written  in  two  different  laguages.  Two  of  tha 
purposes  of  using  HOL  ara  to  cut  costs  and  improve  produc¬ 
tivity.  But  the  example  shows  tha  paradox  of  this  measure. 
It  appears  that  Assembler  language  is  more  productive  than 
tha  HOL  even  though  rha  H3L  program  took  one  month  less  to 
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Activity 

Assembler 

Language 

HOL 

Design 

4  weeks 

4  weeks 

Coding 

4 

2 

Testing 

4 

2 

Documentation 

2 

2 

Mgmt/Support 

2 

2 

Total  Effort 

IS  weeks 

12  weeks 

(4  months) 

(3  months) 

Lines  of  code 

2300 

500 

LOC  per  prog-ion 

5  00 

167 

_ 

j 

Figure  4.1  Assembler  Language  vs  HOL. 

produce.  Notice  also  that  Jones  used  the  term  "programmer- 
month"  to  mean  the  entire  program  development  time,  a  common 
practice,  as  mentioned  earlier.  The  actual  programming 
times  were  one  month  and  one-half  month  for  Assembler 
language  and  HOL,  respectively.  Even  if  this  time  frame  is 
used,  though,  the  Assembler  language  at  2000  LOC  per 
programmer-month  appears  to  be  twice  as  productive  as  the 
HOL  at  1000  LOC  per  programmer-month.  This  points  out  the 
problem  of  not  being  consistent  about  terms.  Jones  uses 
programmer-month  to  mean  the  entire  development  time  which 
yielded  an  average  productivity  figure  which  included  a 
period  when  no  ceding  was  being  done  at  all.  Using  the  term 
strictly  and  comparing  it  to  J ones’  usage  leaves  us  with  a 
four  tc  one  difference  in  productivity  for  Assembler 
language  and  a  six  to  one  difference  in  productivity  for  the 
HOL. 
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B.  HOODIES  PEB  SOUTH 


This  particular  measure  vas  presented  in  a  paper  by 
Crossman  [Ref.  23].  Surpri singly,  tais  researcher  could  not 
find  any  other  references  that  have  attempted  to  duplicate 
his  findings.  Yet  he  pointed  to  several  advantages  which 
this  measure  and  its  methodology  of  program  development 
support. 

Modular  design  programming  usnds  to  minimize  the 
complexity  of  projects.  Minimizing  the  complexity  parameter 
allows  the  manager  to  reduo e  the  number  of  variables  he  must 
consider  when  making  produotivity  comparisons.  The  defini¬ 
tion  of  a  module  appears  to  be  more  consistent  throughout 
industry  than  LOC  which  gives  it  a  potentially  much  better 
comparative  capability  between  organizations,  provided  the 
other  organizations  use  this  measure.  The  use  of  modules  as 
a  product  provides  a  consistency  throughout  the  development 
cycle.  It  includes  the  design,  coding,  testing,  docu¬ 
menting,  and  management/support  phases.  Yet  it  can  also  ba 
broken  down  into  its  individual  component  efforts  to  deter¬ 
mine  which  effort  has  tha  greatest  impact  on  development 
time  and  the  impact  of  aach  module  on  the  project  as  a 
who le. 

C.  FUNCTION  POINT  DELIVERED  PER  iORK  HOUR 

Albrecht  [Ref.  27]  discussed  tha  affects  this  approach 
has  on  showing  the  relative  productivities  between 
languages,  project  size  and  various  programming  technolo¬ 
gies.  The  method  focusss  on  tha  external  attributes  of  a 
program  and  the  work-hours  contributed  by  both  IBM  and 
customer  personnel  assigned  to  work  on  the  project.  It 
covers  all  phases  of  tha  project.  The  goal  of  this  method 
of  measurement  i s  to  stata  development  costs  in  terms  of  the 
work-hours  used  to  design,  program  and  test  the  applications 


project.  Although  there  is  not  enough  data  available 
presently  to  give  conclusive  results,  the  report  does  indi¬ 
cate  the  capability  to  show  the  relative  productivities  of 
different  languages  and  development  technologies.  This  is  a 
major  advantage  that  is  not  possible  with  LOC  and  has  not 
yet  been  explored  using  modules. 
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0.  SELECTED  INDUSTRY  METHODS  FOB  MEASURING  PHODUCTIYITY 

The  preceding  sections  of  this  chapter  discussed  various 
methods  used  in  research  to  study  programmer  productivity. 
Each  method  mentioned  uses  a  ratio  of  outputs  (project, 
program,  specifications,  aodules,  LOZ  or  function  value)  to 
inputs  (person-months,  programmer-months,  or  work-hours). 
Previous  sections  provided  recommended  definitions  for 
selected  output  and  input  components.  This  section  presents 
measures  used  by  several  prominant  corporations  that  develop 
software. 

1.  5§M 


Measurement  of  programs  is  still  a  fairly  subjective 
process.  We  can  measure  size,  based  on  'lines  of  coda' 
or  'number  of  statments',  but  acceptance  of  these 
measures  is  not  universal.  Acceptance  of  lines  of  code, 
as  an  example,  seems  to  be  based  on  the  view  that 
although  lines  of  coda  may  be  an  imprecise  measure,  it 
is  something  that  can  be  enumerated,  and  until  something 
better  is  discovered  we  will  continue  to  use  it.  There 
is  a  veiled  invitation  nere  to  find  something  better, 
reef.  30  ,p.  372] 


This  is  the  philosophy  used  to  approach  the 
measuring  of  programming  activities  at  the  Santa  Teresa 
Laboratory  of  I3M.  The  "something  better"  that  IBM  has  been 
trying  to  refine  for  the  Last  three  to  four  years  has  been 
the  software  science  metrics  developed  oy  Halstead 
[Ref.  31].  Figure  4.2  shows  the  major  elements  in  use  by 
I3M  [Ref.  32]  [Ref.  30].  The  philosophy  for  using  software 
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operands  »  values  that  are  change!  or  used  as  a. 

reference  far  change  (constants,  variables 

Operators  *  elements  that  operate  on  or  with  operands 
(operation  codes,  delimiters,  punctuation, 
arithmetic  symbols,  branches  (00  WHILE, 

IF  THEN,  IP  THEN  ELSE)) 

T] I  =  number  of  unique  operators  used 
V2  =  number  of  unique  operands  used 

=  number  cf  times  the  operators  are  used 


=  number  of  times  the  operands  are  used 


Vocabulary  (7?)  =  the  sum  of  unique  operands  and 
'  operators  used  in  the  program. 

It  is  a  measure  of  the  repertoire 
of  elements  a  programmer  uses  to 
impleaent  a  program. 

^  *V  \ 

Length  (N )  =  the  sum  of  the  operator  usage  and  the 
operand  usage.  It  is  a  measure  of 
program  size. 

N  *  N /  +  *2 


Difficulty  (D) 


D 


a  measure  of  the 
writing  code  and 
measure  of  ease 


N2 

W 


difficulty  0 
,  intuitively 
of  reading. 


* 

A. 

t 


a 


Figure  4.2  Halstead  Element  Relationships. 

science  metrics  is  built  on  zh e  following  beliefs.  First, 
in  any  given  language,  one  type  of  program  is  no  harder  to 
code  than  another.  The  experience  at  Santa  Teresa  labora¬ 
tory  over  the  last  five  years  is  that  the  only  things  that 
affect  productivity  are  the  language  and  the  tools  used. 
They  have  found  that  HOL  is  about  twice  as  productive  as 
Assembler  language.  Second,  aside  from  language,  the 
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development  tools  are  what  affects  programmer  productivity. 
To  this  end,  IBM  has  consistently  aided  to  the  " workbench" 
of  their  programmers..  They  have  provided  on-line  program¬ 
ming  capabilities,  given  each  programmer  his/her  own 
terminal  in  his/her  office,  provided  a  dedicated  program 
development  computer  and  various  programming  aids  such  as 
Script.  Third,  the  definition  of  operators  and  operands  is 
consistent  across  language  barriers.  This  gives  software 
science  metrics  a  significant  advantage  over  other  measures. 
Additionally,  IBM  research  has  shown  that  the  size  metrics 
used  by  Halstead  are  as  accurate  as  LOC  for  measuring 
program  size. 

Since  programming  productivity  is  believed  to  be 
constant  for  all  programmers,  given  the  same  environment, 
IBM  has  looked  primarily  at  the  difficulty  metric. 
Difficulty  is  defined  as  a  metric  that  expresses  the  diffi¬ 
culty  of  writing  code.  It  takes  into  consideration  decision 
nodes,  the  repertoire  of  operators  used  and  how  concise  the 
usage  of  the  variables  is.  The  measure,  then,  also  appears 
to  be  one  for  ease  of  reading.  It  doss  not  tell  how  diffi¬ 
cult  the  program  must  be.  It  only  tells  how  difficult  the 
programmer  made  the  program.  High  difficulty  can  come  from 
poor  programming  skills,  poor  program  structure,  inexperi¬ 
ence  with  the  language  or  the  complexity  of  the  algorithm. 
The  value  of  this  metric  Ls  three  fold.  It  tends  to  indi¬ 
cate  errcr-proneness  much  earlier  in  the  development  cycle 
than  traditional  methods.  Intuitively,  the  more  difficult 
the  program,  the  more  error-prone  it  is.  The  measure  can 
only  be  taken  after  coding  has  bean  completed  but  it  can  be 
calculated  immediately  following  the  first  clean  compile. 
There  is  no  need  to  wait  for  testing.  Secondly,  it  points 
out  those  programs  which  need  rework  due  to  high  difficulty 
values.  Third,  it  points  out  programmers  who  consistently 
have  high  difficulty  values.  This  enables  the  manager  to 


ensure  that  the  programmer  receives  added  training  in  the 
techniques  available  to  reduce  program  difficulty.  IBB  has 
found  that  the  difficulty  measure  tends  to  range  from  three 
to  eight.  When  ever  they  see  that  a  difficulty  aeasure 
exceeds  five,  they  call  the  prograaaer  in  to  have  hia/her 
recode  the  program  to  reduce  the  difficulty  measure  to  five 
or  less.  If  the  programier  consistently  delivers  code  with 
high  difficulty  measures  he/she  is  provided  added  training 
in  techniques  which  can  lower  the  program  difficulty. 

All  this  only  gives  measures  of  the  program  not  the 
prodcuctivity  of  the  programmer.  For  IBB  to  determine  that 
all  programmers  had  the  same  productivity,  they  had  to  test. 
The  test  measure  was  and  continues,  on  a  minor  basis,  to  be 
LOZ  per  person-year.  LOC  is  defined  as  data  declarations 
and  executable  statments.  The  use  of  this  measure,  now,  is 
only  to  check  for  changes  in  productivity  due  to  new  tools 
and  for  reasonable  production  rate  relative  to  the  industry. 
IBM  recognizes  the  comparability  problem  of  the  LOC  measure. 
However,  the  IBM  perceived  industry  average  ranges  between 
800  and  2500  LOC  per  year,  given  the  line  counting  varia¬ 
tions.  They  continue  to  measure  productivity  using  LOC  per 
man-year  to  ensure  that  IBM  remains  wihtin  this  range. 

2 .  Amdahl 

a.  System  Software 

Amdahl's  approach  to  systems  software  develop¬ 
ment  is  different  from  most  of  the  industry.  As  a 
manufacturer  of  IBM  compatible  hardware  and  software,  their 
approach  is  to  use  IBM  software  proiucts  and  modify  them  to 
operate  more  efficiently  on  Amdahl  hardware.  This  means 
placing  "hooks"  into  the  IBM  software  to  operate  special 
Amdahl  procedures.  Since  their  goal  is  develop  more  effi¬ 
cient  software,  these  hooks  must  be  minimal  in  both  length 


and  interference  with  the  existing  software  and  logic. 
Amdahl  places  a  much  higher  emphasis  on  quality  than 
quantity. 

In  this  light,  none  of  the  previously  discussed 
measures  apply.  Amdahl  uses  a  management  by  objectives 
(MBO)  approach  to  measure  performance.  Their  hiring  prac¬ 
tices  aim  towards  acquiring  these  programmers  who  are 
experienced,  skilled  and  senior  in  the  industry.  The 
programmers  are  organized  into  groups  of  two  to  three 
assigned  to  one  team  leader.  Each  group  has  its  own  area  of 
responsibility  fer  program  development/modification.  The 
assignment  of  tasks  and  the  time  coastraints  are  determined 
by  mutual  agreement  between  the  manager  and  team  leader. 
The  schedules  are  recorded  and  each  programmer  is  evaluated 
on  his/her  performance.  The  evaluation  is  discussed  with 
the  respective  programmer  at  the  periodic  performance 
review.  Since  each  group  has  specific  areas  of  responsi¬ 
bility  and  those  areas  are  limited,  any  trouble  reports 
received  are  easily  assigned  to  the  group  and/or  individual 
responsible.  These  are  also  included  in  the  performance 
review.  This  scenario  does  allow  any  specific  measure  to 
quantify  programmer  performance.  However,  the  programming 
section  is  a  small  organization,  53-75  programmers,  so  they 
track  the  type  of  modification  against  the  time  required  and 
the  quality  of  the  programs  ing.  They  do  not  use  any  parti¬ 
cular  measure  outside  of  budget  and  schedule.  'Ref.  33] 

b.  Applications  Software 

Amdahl's  application  program  development  is  very 
similar  to  the  systems  software  development  in  that  they  use 
MB3  as  the  predominant  measure.  They  dc  use  LOC  per 
programmer  year  to  do  soma  measuring  but  it  has  very  little 
significance  to  the  operation.  LOC  is  defined  as  all 
programmer-original  COBOL  statments.  So  credit  is  giver,  for 


reused  code,  although,  they  admit  some  credit  should  be 
given.  This  wculd  appear  to  discourage  reusing  code  but 
their  incentive,  reward  and  penalty  system  provides  the 
necessary  encouragement.  How  the  system  functions  was  not 
specified.  Management  does  require  programmers  to  use  data 
dictionaries,  and  code  libraries  are  kept  in  an  on-line  data 
base.  The  primary  measure  used  to  measure  performance  is  a 
review  of  the  programmer's  schedule.  The  programmer  submits 
a  schedule  of  task  accoip lishment  to  the  manager.  The 
manager  reviews  it  to  ensure  it  is  realistic  and  then 
compares  the  schedule  to  the  task  completion  dates  as  the 
programmer  delivers  the  assigned  ta3k3.  Here,  as  in  systems 
development,  the  primary  ingredient  for  measuring  is 
programmer  and  manager  experience.  *Hef.  34] 

The  measure  used  to  evaluate  maintenance 
programming  is  built  around  the  number  of  trouble  reports 
received.  Each  programming  group  is  responsible  for  mainte¬ 
nance  of  its  assigned  software.  Team  leaders  must  emphasize 
high  quality  in  the  software  to  avoid  having  to  reschedule 
programmers  onto  maintenance  from  development.  This  does 
net  prevent  errors  but  it  does  cut  them  down.  The  main 
emphasis  from  the  Applications  Programming  Manager  is  to 
ensure  as  rapid  a  response  rime  as  possible  on  the  trouble 
reports.  The  required  turnaround  time  for  trouble  reports, 
presently,  is  not  to  exceed  six  montas.  They  use  the  turna¬ 
round  measure  because  it  tends  to  indicate  to  the  users  that 
the  company  is  genuinely  interested  in  the  productivity  of 
software  maintenance.  It  also  gives  the  respective  managers 
an  additional  reason  when  requesting  more  resources. 
Finally,  it  gives  a  business  value  to  organized  maintenance 
because  it  forces  the  various  managers  to  schedule  resources 
for  program  maintenance. 
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Amdahl  uses  program  packages  predominantly  in 
thair  applications  prograiaing  section.  These  packages  come 
with  their  own  documentation  which  allows  Amdahl  to  take 
take  an  approach  significantly  diffarant  from  this  research¬ 
er*  s  view  point.  Amdahl  beliavas  program  code  and 
documentation  to  be  separate  and  uaagual  products.  This 
belief  is  made  possible  because  they  have  programs  that  can 
analyze  code  and  tell  tha  programmer  the  structure  of  the 
code.  therefore,  thay  feel  that  program  maintenance 
without  the  documentation  is  not  as  difficult  one  might 
assume.  However,  documanation  is  encouraged.  The  method 
usad  is  to  request  documantation  and  to  make  it  as  easy  to 
provide  as  possible.  To  make  the  documentation  easier,  it 
is  all  written  on-line  using  Script  and  a  variety  of  user- 
developed  macros  that  provide  soma  graphics  to  enhance  the 
prose.  The  documentation  guality  is  now  much  higher  and  the 
documentation  is  much  easier  for  tha  programmers  to  deliver. 
[Ref.  343 

3.  Systems  Development  Corporation  (SDC) 

SDC*s  cost  estimating  procedures  use  LOC  and  pages 
of  documentation  as  tha  primary  productivity  inputs  to 
compute  costs.  They  catagorize  tha  various  types  of  LOC 
(data  definitions,  executable  statements,  reused  code,  etc.) 
to  determine  the  subtask  cost  for  each  activity.  The  LOC 
are  weighted  by  an  in-house  complexity  measure  which 
includes  parameters  for  program  size,  security,  and  reli¬ 
ability.  Each  productivity  measure  is  computed  relative  to 
tha  type  of  program  (real-time  process  control,  interactive, 
report  generator,  data  base  control,  etc.)  that  was 
produced.  Documentation  is  mesurei  by  pages  produced  per 
day  per  type  of  program.  Although  thay  call  documentation  a 
separate  product,  they  consider  all  projects  to  be  inte¬ 
grated  packages  of  both  software  code  and  documentation. 
[Raf.  35] 


4.  ££W 


TRW  uses  a  weighted  LOC  par  man-month  method  to 
measure  productivity.  Thsy  reviewed  Halstead's  metrics  but 
concluded,  as  did  IBM,  that  source  LOC  is  equivalent  to  tha 
size  metrics  developed  from  counting  operators  and  operands# 
Thay  do  concede  that  tha  difficuitf  metric  daserves  mora 
study  but  they  have  no  ra sources  avialable  at  present  to 
conduct  such  a  study.  They  have  found  that  weighting  the 
LOC  with  an  in  house  factor  for  complexity  and  reliability 
is  sufficient.  The  LOC  is  defined  as  a  delivered  well  docu¬ 
mented  and  well  engineered  line  equal  to  a  card  image.  Tha 
card  image  is  an  eighty  character  line.  Commant  lines  are 
not  included  but  all  lines  which  hoLd  "computing"  informa¬ 
tion  are  (e.g.  job  control  language,  edit  links,  format 
statements,  data  declarations,  exacutable  statements,  etc.). 
TRW  defines  a  man-month,  152  hours,  to  include  all  personnel 
hours  directly  chargeable  to  the  project. 

At  present,  TRW  does  cot  measure  maintenance  produc¬ 
tivity.  However,  the  interview  with  Dr.  Boehm  [Ref.  36], 
recommenced  the  method  discussed  in  his  book  Software 
Sncineerinq  Economics  [Ref.  37].  This  method  equates  the 
annual  maintenance  effort  to  the  annual  change  traffic  (ACT) 
multiplied  by  the  estimated  development  effort.  ACT  is  the 
fraction  of  the  software  product's  source  instructions  which 
undergo  change  during  a  typical  year,  either  through  addi¬ 
tion  or  modification. 

TRW  includes  documentation  in  its  definition  of  a 
LOC.  This  corresponds  with  the  philosophy  of  this 
researcher.  TRW  does  not  treat  software  code  and  documenta¬ 
tion  as  separate  products  but  as  integral  parts  of  the 
software  project. 


7.  fflfifilSSIQMS  A&B  afiQOisigCAHOIS 


This  paper  has  atteapted  to  point  out  the  aajor  areas 
which  nust  be  explored  in  order  to  measure  and  discuss 
programmer  productivity  or  software  development  produc¬ 
tivity.  The  manager  must  decide  what  level  of  the 
organization  he  wishes  to  measure.  He  then  must  determine 
what,  specifically,  the  product  is  which  that  level  is 
making.  Before  proceeding  any  further,  he  should  examine 
the  quality  assurance  procedures  and  practices  to  ensure 
that  they  are  both  in  use  and  that  they  do  establish  and 
check  for  a  minimum  quality  standard.  Prom  here  the  manager 
can  select  the  various  inputs  which  he  feels  are  relevant  to 
study.  The  productivity  rates  he  computes  need  to  be  stored 
in  a  data  base  so  that  they  may  be  used  as  comparators 
against  time  and  other  organizations.  Finally,  each  measure 
must  be  kept  in  the  context  of  its  environment.  This  condi¬ 
tion  provides  two  functions.  First,  it  keeps  the  measure 
meaningful.  Second,  by  selectively  changing  one  element  of 
the  environment  at  a  time,  the  manager  can  determine  cause 
and  effect  relationships  that  can  Lead  to  establishing  the 
optimum  software  development  environment. 

The  LOC  measures  are  poor  for  software  development  and 
lead  to  paradoxical  conclusions  in  many  instances. 
Remaining  with  any  measure  that  uses  LOC  will  tend  to  bind 
the  organization  to  technologies  requiring  the  development 
of  totally  original  code  on  every  project.  This  will  tend 
to  prevent  the  use  of  metaprogramming  and  the  development  of 
program  families.  These  programming  technologies  show 
significant  promise  to  reduce  development  costs  and  improve 
programming  productivity  dramatically. 


Modular  sea  suras  provide  the  opportunity  to  explore  and 
develop  the  aeta programing  practice.  They  also  have  over¬ 
heads  that  aust  be  acceptad  as  development  personnel  learn 
the  technology,  the  aided  effort  required  in  the  design 
phase,  particularly  for  "small”  projects,  and  the  possible 
inefficient  use  of  CPU  time  due  to  an  increase  in  the  number 
of  LOC.  These  are  small  overheads  to  pay  if  the  development 
time  can  be  reduced  by  as  such  as  Laaergan  [Ref.  19]  claims. 
The  measure  can  be  used  in  conjunction  with  any  other 
measure  to  help  define  the  programming  activity  better.  It 
may  be  especially  useful  in  conjunction  with  function 
points. 

In  closing,  it  is  apparent  for  the  literature  and  the 
discussions  with  the  selected  industry  corporations  that 
there  is  no  perfect  and  correct  measure  or  method  for 
measuring  programmer  productivity.  However,  the  vital  point 
to  understand  is  that  nearly  all  organizations  do  measure 
programmer  productivity  in  soma  fashion.  Several  organiza¬ 
tions  admit  that  their  methods  lack  some  possibly  important 
inputs  or  parameters.  However,  each  organization  does 
attempt  to  measure  productivity  so  that  each  can  gain  some 
understanding  of  the  organization's  particular  environment. 
Wish  an  understanding  of  the  environieat,  each  organization 
and  researcher  is  able  to  conceptualize  the  software  devel¬ 
opment  process  so  that  the  manager  can  make  intelligent 
assertions  about  how  it  is  affected. 
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-  Function 
Points 


wi*tile  beckon,  recovery .  and/nr 
aystea  availability  are  provided 
by  the  application  design  or 
implementation.  The  functions 
may  be  provided  by  specifically 
designed  application  code  or  by 
use  of  functions  provided  by 
standard  software.  Tor  example, 
the  standard  IMS  backup  and 
recovery  functions. 

Data  communications  are  provided 
in  the  application. 

Distributed  processing  functions 
are  provided  in  the  application. 

Performance  must  be  considered 
in  the  design  or  lnplsaentetion. 

In  addition  to  considering 
performance  there  is  the  added 
complexity  of  a  heavily  utilised 
operational  configuration.  The 
customer  wants  to  run  the 
application  on  existing  or 
coomitted  hardware  that,  as  a 
consequence,  will  be  heavily 
utilised. 


_  On-line  data  entry  is  provided  in 
the  apyliuuuii. 

_  On-line  data  entry  is  provided  in 
the  application  and  in  addition 
the  data  entry  is  conversational 
requiring  that  an  input  trans¬ 
action  ba  built  up  over  nultiple 
operetione. 

_  Master  files  are  updated  on-line. 


Inputs,  outputs,  fllss,  or 
Inquiries  are  Comdex  in 

this  application. 


Internal  processing  is 
in  this  application. 


Degree  of  Influence  on  Tunction: 

0  None  1  Average 

1  Incidental  4  Significant 

3  Moderate  5  essential 


Total  Degree  of  Influenee  (N) 

Complexity  adjustment  equals  (0.7S  ♦  ft01  WO 

Unadjusted  Total  X  Complexity  Adjustment  •  Function  roints  Delivered  or  Designed 


CwM  all  inputs,  outputs,  Mater  (ilea, 
inquiries,  end  (unctions  that  arc  nede  available 
ta  the  cos toast  through  the  project  a  design, 
programing,  or  tsstinq  efforts,  ror  euaple, 
count  the  functions  provided  by  an  IUP,  rop,  or 
Procraa  product  if  the  package  was  aedified, 
integrated,  tested,  and  thus  provided  to  the 
eustauer  through  tits  project* ■  efforts. 


MPf k-bours i 

the  work-hours  recorded  should  be  the  HM  and 
•"“••r  hours  spent  en  the  DP  Services 
standard  tasks  applicable  to  the  project  phase 
The  custooer  hours  should  be  adjusted  to  ISM 
equivalent  hours  considering  experience, 
train inf .  aad  work  effectiveness. 


Count  each  systeo  output  that  provides  business 
function  eessaunication  f ran  the  caupoter  systeo 
to  the  users,  for  svtoplet 


e  printed  reports 
e  terainal  screens 


a  terminal  printed  output 
s  operator  Mssages 


Count  all  unique  external  outputs,  an  output 
considered  to  be  unique  if  it  has  a  format 
that  differs  from  other  external  outputs  and 
inputs,  or,  if  it  requires  unique  processinq 
loqic  to  provide  or  calculate  the  output  data. 

Do  not  include  output  tern Inal  screens  that 
provide  only  a  staple  error  nessaqe  or 
acknowledgement  of  the  entry  transaction, 
unless  significant  unique  proeeseinq  loqic 
is  required  in  addition  to  the  edltlnq 
associated  with  tha  input,  which  was  counted. 


Do  not  include  on-line  Inquiry  transaction 
outputs  Where  the  response  occurs  innediately. 
Those  are  included  in  a  later  question. 


Count  each  systeo  input  that  provides  business 
function  coununication  from  the  users  to  the 
oooputer  systeo  for  example t 

o  data  forma  e  scanner  forms  or  earda 

a  terminal  acrvens  e  keyed  transactions 

Do  not  double  count  the  inputs,  for  exanple, 
consider  a  sianual  operation  that  takes  data 
from  an  input  loro,  to  form  two  input  screens, 
ualnq  a  keyboard  to  form  each  screen  before  the 
entry  key  is  pressed.  This  should  be  counted 
as  two  (2)  inputs  not  five  (1). 

Count  all  unique  Inputs.  An  Input  transaction 
should  be  counted  as  unique  if  it  required 
different  processinq  loqic  than  other  inputs. 

Por  example,  transactions  such  as  add,  delete, 
or  chanqe  My  have  exactly  the  same  screen 
format  but  they  should  be  counted  as  unique 
Inputs  if  they  require  different  processinq 
logic. 

Do  not  count  Input  or  output  terminal  screens  that 
ere  needed  by  the  system  only  because  of  the 
specific  technical  implementation  of  the 
function.  For  example,  QMS /VS  screens,  that 
are  provided  only  to  qet  to  the  next  screen 
and  do  not  provide  a  business  function  for  the  1 
user,  should  net  be  counted. 

Do  not  count  input  and  output  tape  and  file  data 
seta.  These  are  included  in  the  count  of  files. 

Do  not  count  inquiry  transactions.  These  are 
covered  in  a  subsequent  question. 


file  Count i 

Count  each  unique  MChine  readable  logical 
fild,  or  logical  grouping  of  date  from  the 
viewpoint  of  the  user,  that  is  generated, 
used,  or  Mlntained  by  the  systeo.  for 
example i 


Input  card  files 
disk  files 


e  tape  files 


Count  Mjor  user  data  groups  within  a  data  base. 
Count  loqical  files,  not  physical  data  sets, 
for  example,  a  customer  file  requiring  a 
separate  index  file  because  of  the  access 
Mthod  would  be  counted  as  one  loqical 
file  not  two.  However,  an  alphabetical 
index  file  to  aid  in  establishing  customer 
identity  would  be  counted. 

Count  all  machine  readable  interfaces 
to  other  system  as  files. 


Inouirv  Count: 


Count  each  input/response  couplet  where  an  on¬ 
line  input  generates  and  directly  causes  an 
immediate  on-line  output.  Data  is  not  entered 
except  for  control  purposes  and  therefore  only 
transaction  logs  are  altered. 

Count  each  uniquely  formatted  or  uniquely 
processed  inquiry  which  results  in  a  file  seam 
for  specific  information  or  summaries  to  be 
presented  as  response  to  that  inquiry. 

Do  not  also  count  inquiries  as  inputs  or 
outputs. 
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OF  SERVICES  DESIGN  PHASE 

SIZE  AND  COMPLEXITY  FACTOR  ESTIMATOR  FORM 


Section  6.2 
12-31-78 


QUESTION 


1.  SCOPE  OF  THE  INVOLVEMENT  WITHIN  THE  COMPANY 

a.  Company  Functional  Organizations: 

Identify  the  number  of  independent  organizational  entities  which 
will  be  involved  either  directly  or  indirectly  in  the  project 
For  example,  if  the  system  includes  two  business  functions 
inventory  control  and  billing,  at  least  two  organizations 
probably  would  be  involved.  Direct  involvement  refers  to  actual 
participation  in  the  requirement  study  or  design.  Indirect 
involvement  refers  to  review  and  approval  of  the  requirements  or 
design.  The  organizations  may  be  counted  separately  in  each 
location.  For  example,  if  the  accounting  department  has  a 
subdepartment  in  each  of  three  geographic  locations,  and  if  each 
must  either  be  interviewed  or  included  in  the  approval  cycle, 
then  the  accounting  function  should  be  counted  as  three 
organizations  rather  than  one.  Always  include  the  data 
processing  organization. 

b.  Company  Locations: 

Identify  the  number  of  company  locations  that  require  travel  for 
information,  interviews  or  approvals.  The  primary  location  must 
also  be  counted.  Each  city  involved  would  be  a  location.  Where 
multiple  locations  exist  in  the  same  city,  consider  each  as  half 
a  location. 

c.  Number  of  people  in  the  organizations  involved: 

Identify  the  number  of  hundreds  of  people  in  each  organization 
identified  in  question  la)  above.  For  example,  a  project 
involving  two  organizations,  one  with  135  people,  and  one  with  50 
people  would  count  as  three  hundreds  of  people.  This  provides  a 
definition  of  complexity  of  interviews  and  requirements 
definition. 


2.  FUNCTIONAL  SIZE  OF  THE  APPLICATION 
a.  Number  of  Major  Subsystems: 
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1.  SCOPE  OF  THE  INVOLVEMENT  WITH  THE  COMPANY 


a.  Number  of  company  functional 

organizations  involved:  _ x  4  * 


b.  Number  of  company  locations 

involved:  _ X  12  * 


x  2  « 


c.  Number  of  100  (a)  of  people  in 
the  involved  organizations: 


«■  - .  -  , 
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In  general,  a  major  subsystem  is  equivalent  to  a  major 
application  or  system  function.  Examples  of  subsystems  within  an 
Order  Processing  System  might  bet 

Order  Entry 
Accounts  Receivable 
Inventory  Update 
Inventory  Replenishment 
Shipping 

Recovery  and  Restart 
Invoicing 

Management  Reporting 
File  Administration 
File  Conversion 

If  you  think  that  a  function  is  logically  separable  and 
reasonably  significant  in  size  then  count  it  as  a  subsystem. 

b.  Number  of  External  Inputs: 

This  question  addresses  all  system  input  vehicles  that  provide 
business  function  communication  from  the  users  to  the  computer 
system  (e.g. ,  data  forms,  terminal  screens,  keyboard 
transactions,  optical  scanner  forms).  It  does  not  include 
internal  inputs  such  as  tape  and  file  data  sets.  These  are 
included  in  the  count  of  files.  It  should  not  include  input 
screens  that  are  needed  by  the  design  only  because  of  the 
specific  implementation  (e.g.,  DMS/VS  screens  that  are  only 
provided  to  get  to  the  next  screen  but  do  not  provide  input  of  a 
business  function  or  business  information  for  the  terminal  user. ) 

It  should  include  the  inputs  associated  with  all  the  functions 
committed  in  the  design.  If  such  functions  as  File  conversion 
and  Data  Base  Maintenance  are  to  be  supported  their  inputs  must 
be  counted  even  if  they  are  used  only  once. 

On-line  inquiry  transactions  should  not  be  counted  here  since 
they  are  included  separately  in  a  later  question. 

The  objective  of  this  question  is  to  enumerate  all  unique  inputs. 
An  input  transaction  should  be  counted  as  unique  if  there  is  any 
possibility  that  it  will  require  different  processing  logic  than 
other  transactions.  For  example,  transactions  which  have  exactly 
the  same  screen  format  and  differ  only  in  a  code  used  to  indicate 
transaction  type  (e.g.,  add,  delete,  change)  should  each  be 
counted  separately  as  unique  transactions. 

c.  Number  of  External  Outputs: 
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As  with  the  External  Inputs  this  question  addresses  all  system 
output  vehicles  that  provide  business  function  communication  from 
the  computer  system  to  the  users  (e.g. ,  printed  reports,  output 
screens,  hard  copy  terminal  output  operator  messages).  On-line 
inquiry  transactions,  where  the  response  occurs  immediately  on¬ 
line  should  not  be  included  in  this  count.  However,  printed 
reports  which  are  triggered  by  off-line  or  on-line  inquiries 
should  be  included  in  this  count.  The  count  should  not  inlcude 
output  screens  that  are  needed  by  the  design  only  because  of  the 
specific  implementation  (e.g.,  DMS/VS  screens  that  are  only 
provided  to  get  to  the  next  screen  but  do  not  provide  a  business 
function  or  business  information  for  the  terminal  user.) 

An  output  is  considered  to  be  unique  if  it  has  its  own  format 
which  differs  from  other  external  outputs,  or  if  it  requires 
unique  processing  logic  to  provide  or  calculate  the  output  data. 

d.  Number  of  Filest 

This  count  should  include  each  planned  unique  machine  readable 
logical  file,  or  logical  grouping  from  the  viewpoint  of  the  user, 
that  is  to  be  generated  by  or  input  to  the  system  (e.g.,  card 
types,  data  base  files,  disk  files,  tape  files).  This  question 
is  oriented  toward  logical  files  not  physical  data  sets.  For 
example,  a  customer  file  requiring  a  separate  index  file  because 
of  the  access  method  chosen  during  design  would  be  counted  as  1 
logical  file  not  2.  However,  a  special  alphabetical  index  file 
to  aid  in  establishing  customer  identity  would  be  counted 
separately. 

This  count  should  include  all  machine  readable  interfaces  to 
other  computer  systems. 

e.  Number  of  on-line  Inquiry  typess 

This  question  addresses  conversational  input/response  couplets 
where  the  on-line  input  generates  and  directly  causes  an 
immediate  on-line  output.  These  couplets  generally  do  not  enter 
data  except  for  control  purposes  and  therefore  alter  only 
transaction  logs. 

In  determining  this  count  consider  each  uniquely  formatted  or 
uniquely  processed  inquiry  (input/response  pair)  which  results  in 
a  file  search  for  specific  information  or  summaries  of  groups  of 
information  to  be  presented  as  output  response  to  that  inquiry. 


Inquiries  should  not  also  be  counted  as  inputs  or  outputs. 
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3.  COMPLEXITY  OF  THE  OVERALL  DESIGN  PHASE 

a.  Customer  Capability: 

Consider  whether  the  customer  has  data  processing  or  user 
capability  that  will  provide  a  good  environment  for  requirements 
definition  and  system  design  or  whether  his  people  will  require 
more  that  normal  explanation  and  justification  for  routine 
decisions. 

On  the  other  hand  does  the  customer  have  so  much  expertise  that 
his  design  convictions  will  complicate  the  job  beyond  that 
normally  expected,  (e.g.,  an  application  well  suited  to  IMS  but 
the  customer  wants  to  develop  his  own  TCAM  data  base  system. ) 

Both  situations  would  hinder  the  project.. 

b.  Existing  Customer  Function* 

Does  the  customer  currently  perform  the  business  functions  that 
are  to  be  included  in  the  system  or  is  this  a  new  business  area? 

An  example  of  a  new  function  that  would  result  in  a  "no”  answer 
would  be,  an  insurance  company  that  does  not  currently  handle 
group  dental  pl^ns  but  wants  to  develop  an  automated  system  to 
process  group  dental  claims  so  that  they  can  compete  for  that 
type  of  business. 

c.  Existing  EDP  System* 

If  the  answer  to  the  previous  question  was  No,  then  this  question 
must  also  be  answered  No.  If  the  customer  currently  is 
performing  the  majority  of  the  business  functions  to  be  included 
in  the  system  and  a  significant  number  of  these  are  being 
supported  by  existing  EDP  system(s),  the  answer  should  be  Yes. 
otherwise,  the  answer  is  No. 

d.  First  of  a  Kind: 

Has  this  application  ever  been  computerized  before,  anywhere?  Is 
this  the  first  attempt  to  automate  a  significant  business 
function  in  the  application?  A  Yes  to  either  question  should 
make  this  system  the  First  of  a  Xind. 

e.  Hardware  and  Software  Operational  Environment: 

This  question  is  addressing  the  overall  complexity  of  the 
estimated  operational  system.  An  example  of  a  Simple  system 
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3.  COMPLEXITY  OF  OVERALL  DESIGN  PHASE 


a.  Will  the  customer's  capability  hinder: 
No  (0),  Yes  (10)  _ 


b.  Existing  customer  function  to 
be  automated: 

NO  (10),  Yes  (0) 


c.  Does  an  EDP  system  exist  now 
to  perform  the  function: 

No  (6) ,  Yes  (0) 


d.  Is  this  system  the  first  of  its 
kind  anywhere: 

No  (0) ,  Yes  (10) 


I 


I 


DP  SERVICES  DESIGN  PHASE 

SIZE  AND  COMPLEXITY  FACTOR  ESTIMATOR  FORM 


Section  6.2 
12-31-78 


environment  would  be  S/370  Models  115  or  125,  DOS  or  DOS/VS  and 
the  IBM  Standard  TP  and  data  base  products  that  operate  on  that 
level  CPU. 

An  example  of  an  In  Between  system  environment  would  be  S/370 
models  135  or  145,  DOS,  DOS/VS  or  OS/VS  and  CICS  or  DL/I  or 
something  equivalent. 

Large  computers  or  more  sophisticated  operating  System  (e.g. , 
MVS)  or  TP  or  DB  environment  (e.g.,  IMS  or  TCAM)  would  be 
considered  as  Complex.  Distributed  processing  and  programmable 
terminals  would  also  be  considered  complex. 


4.  SOPHISTICATION  EXPECTED  OF  THE  SYSTEM 

a.  In  answering  the  availability  question  consider  how  important  it 
is  that  the  system  be  kept  available  to  the  users.  The  whole 
data  processing  system  including  communications  and  terminals 
should  be  considered.  Can  work  be  postponed? 

Hill  components  be  duplicated  to  increase  system  availability? 
This  can  indicate  critical  availability.  Hill  the  system  be 
designed  to  recover  quickly  from  failure?  This  can  indicate 
important  availability. 

A  batch  system  usually  requires  normal  availability.  A  data 
collection  system  with  non-perishable  inputs,  such  as  paper  claim 
forms,  might  justify  important  availability.  A  passenger 
reservation  system  or  bank  funds  transfer  system  might  require 
critical  availability. 

b.  Hill  a  major  or  important  design  consideration  be,  that  each 
operation  or  function  identified  as  critical  have  an  alternate 
method.  The  alternate  may  involve  manual  operations  and  may  take 
longer  but  the  function  is  provided. 

c.  Hill  the  system  contain  data  that  must  be  protected  against  loss? 
Hill  the  function  require  special  recovery  design  in  either 
procedures  or  system?  If  so,  the  answer  is  yes. 

d.  Data  Traffic  Load  or  System  Performance: 

In  some  systems,  the  volume  of  data  to  be  handled  is  not  a  design 
concern.  Other  systems  require  special  design  considerations 
such  as:  use  of  file  access  optimization,  simplified  input 
notation,  or  extensive  use  of  exception  reporting.  Transaction 
rates  may  be  a  problem  in  either  on-line  or  batch  systems.  Large 
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e.  Hardware  and  software  system 
operational  environment  to  be 
required  by  the  application: 

Simple  (0) ,  In-between  (5)  ,  complex  (10) 


F3 


«.  SOPHISTICATION  EXPECTED  OF  THE  SYSTEM 

a.  Availability  is:  Critical  (8), 
Important  (4),  Normal  (0) 

b.  Is  an  alternate  method,  for 
performing  the  functions  of  the 
system,  non-routine  consideration: 
No  (0),  Yes  (6) 

c.  Is  system  recovery  or  protection 
against  data  loss  a  non-routine 
cons idera tion : 

No  (0),  Yes  (5) 
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volumes  of  data  in  short  periods  (peak  loads)  or  volumes  of  data 
large  enough  to  cause  machine  availability  problems  are  all 
considered  data  traffic  considerations. 

System  performance  is  often  a  significant  design  consideration  in 
systems  that  are  intended  to  handle  large  volumes  of  data.  It 
can  also  be  of  major  concern  in  the  design  of  systems  with 
relatively  low  transaction  rates  but  with  constraints  (perhaps 
economic)  in  terms  of  the  prescribed  hardware  and  software 
environment.  For  example,  there  may  be  limitations  on  the  size 
of  main  storage,  control  program  multi -programming  capabilities, 
or  transmission  line  speeds. 

e.  Nature  of  the  Application! 

A  batch  system  operates  as  a  job  shop,  often  scheduled. 
Transactions  are  typically  batched  external  to  the  computer  and 
periodically  processed  sequentially  against  the  master  files. 

An  on-line  system  generally  requires  a  more  sophisticated 
man/machine  interface  than  a  batch  system.  It  is  generally  a 
system  where  transactions  are  entered  as  they'  are  received  with 
no  opportunity  for  time  saving  sorting.  The  inputs  are  not 
perishable  (i.e.,  they  can  be  re-entered  if  necessary).  An  on¬ 
line  order  entry  system,  or  an  on-line  stock  location  and 
inventory  control  system  would  be  examples  of  on-line. 

A  real-time  system  is  similar  to  an  on-line  system  in  that  it  is 
available  on  demand,  but  it  has  an  additional  requirement  to  not 
postpone  its  main  line  processing.  Response  time  is 
exceptionally  important.  Immediate  processing  and  response  is 
necessary  to  meet  the  functional  requirements  of  the  system. 
Process  control,  production  test  stand  control,  and  airline 
reservation  systems  are  examples  of  real-time  systems  where 
degraded  performance  may  cause  lost  production  or  lost  business. 


f.  Processing  Complexity: 

This  question  addresses  the  internal  processing  logic  required  to 
provide  the  majority  of  the  proposed  system  functions. 
Straightforward  logic  would  involve  simple  transformations  or 
mapping  from  the  system  inputs  or  files  to  the  system  outputs. 

For  example,  a  transaction  is  read,  verified  to  a  limited  degree 
and  used  to  update  a  simple  master  file  or  to  generate  a  simple 
report.  Processing  is  a  straightforward  set  of  pre-specified 
rules.  Few,  if  any,  data  transformations  are  done.  Outputs  are 
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d.  is  data  traffic  load  or  system 
performance  an  important 
design  consideration : 

No  (0),  Either  (10),  Both  (20) 


e.  Nature  of  the  Application: 

Batch  (0) ,  On-Line  (10),  Real-Time  (20) 
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■ostly  collections  in  various  sets,  of  established  data  from 
files. 

Coupler  should  be  checked  if  the  systen  has  a  preponderance  of 
exception  processing  resulting  in  many  incomplete  transactions 
that  must  be  resolved  later  or  again.  Complex  logic  would  also 
be  the  answer  if  there  are  many  interactions  and  decision  points 
and  extensive  logical  or  mathematical  equations.  In-between  is 
used  if  it  fails  to  meet  either  of  the  above  definitions. 

g.  Exception  Correction i 

Systems  which  are  designed  primarily  to  process  correct  data  and 
to  detect  and  present  bad  or  unusual  data  for  manual  review  and 
correction  are  manual  exception  systems.  If  the  system  is  to  be 
designed  not  only  to  detect,  but  also,  automatically  to  correct  a 
significant  number  of  unusual  conditions,  the  system  is  an 
automatic  exception  system.  This  is  true  even  if  the  options 
selected  or  corrections  applied  are  to  be  reviewed  and  verified 
manually. 


5.  KNOWLEDGE  WE  HAVE  FOR  THIS  PROJECT 

a.  Consider  the  Services  Area  in  general  and  specifically  the  people 
who  may  influence  the  project  through: 

•  Project  Management 

•  proposal  preparation 

•  Systems  Assurance 

•  Project  Team  Performance 

Consider  the  Area's  current  knowledge  and  the  available  Industry 
knowledge.  If  none  of  the  people  in  the  performing  Area  have 
designed  or  implemented  this  type  of  application  before,  the 
answer  should  be  Completely  New.  If  informed  consultation  and 
review  is  available  with  people  in  the  Area  the  answer  should  be 
Some  Familiarity.  If  Services  people,  clearly  expected  to 
participate  significantly  in  the  proposal  and  project,  are 
currently  assigned  to  the  performing  Area  and  have  recently 
performed  on  a  similar  project  the  answer  may  be  Have  Done 
Similar  Job  Once. 

b.  To  answer  Extremely  Thorough  the  proposal  should  contain  a 
technical  baseline  that  shows  excellent  understanding  of  the 
tasks  in  the  Statement  of  Work.  The  Customer  User,  IBM  Branch, 
and  DP  Services  must  have  contributed  and  concurred  with  the 
approach.  Everything  else  should  be  moderate  unless  we  lack 
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f.  Processing  complexity: 
Straightforward  (0), 

Complex  (30) ,  In-between  (IS) 


g.  Exception  Correction  is  mostly: 
Manual  (0),  Automatic  (20) 


5.  KNOWLEDGE  WE  SAVE  FOR  THIS  PROJECT 

a.  How  familiar  is  the  proposed 

Services  Area  with  this  Application 
Completely  New  (30) ,  Some 
Familiarity  (IS) ,  Have  done 
Similar  job  once  (0) 
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customer  agreement  either  through  lack  of  contact  or  because  of 
direct  disagreement. 


6.  READINESS  TO  PERFORM  THIS  PROJECT 

a.  Consider  the  location  of  the  project  with  respect  to  the  home 
location  of  the  people  expected  to  work  on  it.  Unless  local 
commuting  habits  and  ground  rules  indicate  otherwise,  travel  of 
more  than  one  hour  each  way  to  the  work  location  should  be 
considered  Significant  Commuting. 

b.  Consider  the  proposed  manning  on  the  project.  Normally  the 
manning  on  DP  Services  projects  cones  from  DP  Services,  the  IBM 
Branch,  or  the  Customer.  If  the  manning  is  proposed  with 
elements  other  than  these,  (i.e.,  subcontract  or  shop  order)  mark 
an  equivalent  answer  from  the  viewpoints  of  Project  Management 
control  and  the  resource's  ability. 

c.  All  temporary  or  permanent  moves  of  project  team  members  should 
be  considered  whether  they  involve  IBM  people  or  customer  people. 


THE  SIZE  AND  COMPLEXITY  FACTOR  COMPUTATION » 

TO  compute  the  Design  Phase  Size  and  Complexity  Factor  that  will  be  used 
to  validate  the  task-by-task  estimate  follow  these  steps: 

1.  Review  and  sum  up  the  weighted  answers  to  the  questions  to 
determine  factors  FI  through  F6. 

2.  Enter  FI  through  F6  and  evaluate  the  equations  on  page  19. 

3.  Sum  the  results  of  (l),  (2)  and  (3)  to  obtain  the  Design  Phase 
Size  and  Complexity  Factor. 


ESTIMATE  VALIDATION: 

Use  the  Design  Phase  Size  and  Complexity  Factor  and  the  plots  provided 
in  Section  6.2  to  determine  the  average  number  of  hours  that  the 
standard  tasks  took  on  completed  DP  Services  projects  with  similar 
Design  Phase  Size  and  Complexity  Factors.  Enter  these  hours  in  the 
appropriate  blanks  on  page  20. 

If  the  data  is  sparse,  the  information  on  each  standard  task  may  not  be 
provided  as  a  separate  number.  However,  the  hours  spent  on  that  task 
are  in  the  totals  and  in  the  associated  standard  task.  Ce.g. ,  the  hours 
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b.  Services  Preproposal  Analysis t 
Extremely  thorough  (0) , 

Moderate  (10),  No  customer  agreement  with 
approach  (20) 


FS 


6.  READINESS  TO  PERFORM  THIS  PROJECT 

a.  Where  is  project  to  be  located: 

No  unusual  commuting  (0), 

Significant  Commuting  (5) , 

Temporary  or  permanent  moves 
required  (10) 

b.  Manning : 

All  Services  (0),  Mixed  IBM  Manning  (5), 
Customer  and  IBM  Mixed  (10) 

c.  Number  of  temporary  and  permanent 
moves  required 

x 
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for  implementation  planning  may  not  be  separately  identified,  bat  they 
would  be  in  the  internal  system  design  task  and  in  the  total  hours. > 

Map  the  task-by-task  estimate  into  the  same  standard  tasks  and  compare 
the  estimates.  The  Proposal  Manager  should  analyze  and  explain  any 
differences  or  make  the  appropriate  adjustments  in  the  task-by-task 
estimate  and  the  proposal. 


FEEDBACK  PROJECT  RESULTS J 

After  the  project  is  completed  and  the  PCAR  is  available,  adjust  the 
Design  Phase  Size  and  Complexity  Factor.  The  factor  needs  to  be 
adjusted  to  account  for  changes  (approved  PCR(s))  that  occurred  during 
the  project.  This  adjustment  provides  a  factor  that  should  be  related 
to  the  completed  project's  results: 

Original  S  6  C  -  The  original  size  and  complexity  factor  computed 

at  proposal  time  on  page  19. 

Change  Hours  -  The  total  estimated  hours  of  approved  changes 

taken  from  the  PCAR. 

Total  Hours 

Multiplier  -  The  current  factor  multiplier  for  the  total 

hours  plot  in  the  design  phase  estimator. 

Adjusted  S  6  C  -  The  size  and  complexity  factor  used  for  project 

feedback  of  results  adjusted  for  the  approved 
changes. 

Adjusted  S  *  C  *  chance  Hours  ♦  Original  S  *  C 

Total  Hours  Multiplier 

The  results  of  the  completed  project  standard  tasks  and  the  delivered 
reports  are  also  taken  from  the  PCAR.  If  the  project  does  not  represent 
a  complete  design  phase,  the  numbers  must  be  used  with  care.  (e.g. ,  a 
requirements  only  design  phase  can  give  a  good  requirements  number.  It 
certainly  won't  give  any  design  numbers.  Less  obviously,  it  won't  give 
any  management  numbers  or  total  hours  numbers  either) . 
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Total  Hours  _  ______ 

system  Design  _______  _____ 

External  System  Design  ______  ______ 

Internal  System  Design  _ 

Implementation  Plan  _____  _____ 

Requirements  Definition  *'  _  _____ 

Orientation  _  _ 

Management  _____  _____ 

System  Design  Report  Size  "  _____ 

Requirements  Report  Size  _____ 
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FEEDBACK  OF  RESULTS: 

Adjust  Size  end  Complexity  Factor:  Bv:  Pate: _ 
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Management  _ 

System  Design  Report  size  _____ 

Requirements  Report  Size  _____ 
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